Re: New package: makeself-2.1.5-2
david sastre wrote: New package "makeself-2.1.5-2" has been uploaded. makeself is a small shell script that generates a self-extractable archive from a directory. The resulting file appears as a shell script (many of those have a .run suffix), and can be launched as is. The archive will then uncompress itself to a temporary directory and an optional arbitrary command will be executed (for example an installation script). Makeself archives also include checksums for integrity self-validation (CRC and/or MD5 checksums). Usage: makeself.sh [params] archive_dir file_name label [startup_script] [args] More info: makeself -h Shouldn't this be: $ makeself.sh -h ? Not that I want extraneous extensions, anyways. Why are we using the '.sh' extension with 'makeself', again? man makeself Does it make sense that?: $ man makeself works but: $ makeself -h doesn't? If you have questions or comments, please send them to the cygwin mailing list at: cygwin@cygwin.com . To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. makeselflessLee ;-) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: New package: makeself-2.1.5-2
Hello, >Shouldn't this be: >$ makeself.sh -h ? Yes. The correct way to invoke makeself is calling `makeself.sh'. /usr/bin/makeself-header.sh /usr/bin/makeself.sh >Why are we using the '.sh' extension with 'makeself', again? Upstream sources keep the extension, other distros strip it, i.e. Debian It looks like there is not a strict policy defined, anyway: $ ls /usr/bin | egrep "\.(pl|py|sh|rb)" | wc -l 161 Regards. 2010/4/28, Lee D. Rothstein : > david sastre wrote: >> New package "makeself-2.1.5-2" has been uploaded. >> >> makeself is a small shell script that generates a self-extractable >> archive from a directory. The resulting file appears as a shell script >> (many of those have a .run suffix), and can be launched as is. The >> archive will then uncompress itself to a temporary directory and an >> optional arbitrary command will be executed (for example an installation >> script). Makeself archives also include checksums for integrity >> self-validation (CRC and/or MD5 checksums). >> >> Usage: >> >> makeself.sh [params] archive_dir file_name label [startup_script] [args] >> >> More info: >> >> makeself -h >> > > Shouldn't this be: > > $ makeself.sh -h ? > > Not that I want extraneous extensions, anyways. > > Why are we using the '.sh' extension with 'makeself', again? > >> man makeself >> > Does it make sense that?: > > $ man makeself > > works but: > > $ makeself -h > > doesn't? > >> If you have questions or comments, please send them to the cygwin >> mailing list at: cygwin@cygwin.com . >> >> To update your installation, click on the "Install Cygwin now" link on >> the http://cygwin.com/ web page. This downloads setup.exe to your >> system. Then, run setup and answer all of the questions. >> >> *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** >> >> If you want to unsubscribe from the cygwin-announce mailing list, look >> at the "List-Unsubscribe: " tag in the email header of this message. >> Send email to the address specified >> there. It will be in the format: >> >> cygwin-announce-unsubscribe-you=yourdomain@cygwin.com >> >> If you need more information on unsubscribing, start reading here: >> >> http://sourceware.org/lists.html#unsubscribe-simple >> >> Please read *all* of the information on unsubscribing that is >> available starting at this URL. >> >> > > makeselflessLee ;-) > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: New package: makeself-2.1.5-2
On Wed, Apr 28, 2010 at 05:33:03PM +0200, David Sastre wrote: > 2010/4/28, Lee D. Rothstein : ^^^ Ouch...! There is something _evil_ in those webmails. Sorry. *goes to write 100 times PCYMTNQREAIYR in the blackboard* -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB pgppJpX3H1ytY.pgp Description: PGP signature
Re: New package: makeself-2.1.5-2
> 2010/4/28, Lee D. Rothstein : >FWIW, the man page says makeself, not makeself.sh. Fair enough. Two options, then: -patching the manpage -patching the source and the cygport None of them involve too much work. So now I would like to know (from some authoritative source :)) if a there is a guideline, an unspoken agreement, or a good practice defined regarding the extension of non-binary executables under /usr/bin. Otherwise, I understand it is left to my choice. Regards. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB pgpBLf67tPXGD.pgp Description: PGP signature
Re: New package: makeself-2.1.5-2
On 04/28/2010 12:12 PM, d.sastre.med...@gmail.com wrote: >> 2010/4/28, Lee D. Rothstein : >> FWIW, the man page says makeself, not makeself.sh. > > Fair enough. > Two options, then: > > -patching the manpage > -patching the source and the cygport > > None of them involve too much work. So now I would like to know (from > some authoritative source :)) if a there is a guideline, an unspoken > agreement, > or a good practice defined regarding the extension of non-binary executables > under /usr/bin. Perhaps unspoken, but I prefer suffix-less executables. Then I don't have to care whether they are binary or interpreted scripts. Besides, having a suffix makes it harder to reimplement in a different language (for example, suppose someone decided to rewrite makeself in C, python, or perl, instead of sh). So following debian practice of stripping the .sh suffix as part of the packaging effort seems reasonable (and in the meantime, perhaps you may also want to report this upstream as a bug they might want to fix). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: New package: makeself-2.1.5-2
Eric Blake wrote: > On 04/28/2010 12:12 PM, Sastre wrote: >>> 2010/4/28, Lee D. Rothstein >>> FWIW, the man page says makeself, not makeself.sh. I actually didn't say that, but I alluded to it. >> Fair enough. >> Two options, then: >> >> -patching the manpage >> -patching the source and the cygport >> >> None of them involve too much work. So now I would like to know (from >> some authoritative source :)) if a there is a guideline, an unspoken agreement, >> or a good practice defined regarding the extension of non-binary executables >> under /usr/bin. > > Perhaps unspoken, but I prefer suffix-less executables. Then I don't > have to care whether they are binary or interpreted scripts. Besides, > having a suffix makes it harder to reimplement in a different language > (for example, suppose someone decided to rewrite makeself in C, python, > or perl, instead of sh). So following debian practice of stripping the > .sh suffix as part of the packaging effort seems reasonable (and in the > meantime, perhaps you may also want to report this upstream as a bug > they might want to fix). First some important medical information: Suffixes cause cancer in dogs learning to play the piano. A lot of the contributors, here, apparently, have such pets. ;-) Now, my opinion: Amen, to what Erick Blake said. No suffixes, please. Debian has it right. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: New package: makeself-2.1.5-2
On Wed, Apr 28, 2010 at 12:19:27PM -0600, Eric Blake wrote: > On 04/28/2010 12:12 PM, d.sastre.medina wrote: > >> 2010/4/28, Lee D. Rothstein: > >> FWIW, the man page says makeself, not makeself.sh. > > > > Fair enough. > > Two options, then: > > > > -patching the manpage > > -patching the source and the cygport > > > > None of them involve too much work. So now I would like to know (from > > some authoritative source :)) if a there is a guideline, an unspoken > > agreement, > > or a good practice defined regarding the extension of non-binary > > executables > > under /usr/bin. > > Perhaps unspoken, but I prefer suffix-less executables. Then I don't > have to care whether they are binary or interpreted scripts. Besides, > having a suffix makes it harder to reimplement in a different language > (for example, suppose someone decided to rewrite makeself in C, python, > or perl, instead of sh). So following debian practice of stripping the > .sh suffix as part of the packaging effort seems reasonable (and in the > meantime, perhaps you may also want to report this upstream as a bug > they might want to fix). I committed several changes: -Executable files have had their .sh extensions stripped. -makeself-header moved out of /usr/bin into /usr/share/makeself. -makeself-2.1.5-3.cygport file modified accordingly. -README file updated using script provided with upstream sources. Hopefully I'll RFU tomorrow. Thanks Lee for the report and Eric for the suggestions. Best regards. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB pgppf86PWiH4o.pgp Description: PGP signature
Re: New package: makeself-2.1.5-2
On Wed, Apr 28, 2010 at 05:44:34PM -0400, Lee D. Rothstein wrote: > >>> 2010/4/28, Lee D. Rothstein > >>> FWIW, the man page says makeself, not makeself.sh. > > I actually didn't say that, but I alluded to it. That is true: From: "Lee Maschmeyer" It was another Lee... > > First some important medical information: > > Suffixes cause cancer in dogs learning to play the piano. A lot > of the contributors, here, apparently, have such pets. ;-) Some day I'll get those jokes about dogs playing pianos, super-cows, hippos and stuff... > Now, my opinion: > > Amen, to what Erick Blake said. No suffixes, please. Debian has > it right. Done. Thanks four your time. Regards. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB pgpD93Pjutf4e.pgp Description: PGP signature
RE: New package: makeself-2.1.5-2
> From: Eric Blake > Sent: Wednesday, April 28, 2010 14:19 > To: cygwin@cygwin.com > Subject: Re: New package: makeself-2.1.5-2 > > ... > Perhaps unspoken, but I prefer suffix-less executables. Then I don't > have to care whether they are binary or interpreted scripts. Besides, > having a suffix makes it harder to reimplement in a different language > (for example, suppose someone decided to rewrite makeself in C, python, > or perl, instead of sh). So following debian practice of stripping the > .sh suffix as part of the packaging effort seems reasonable (and in the > meantime, perhaps you may also want to report this upstream as a bug > they might want to fix). > > -- > Eric Blake ebl...@redhat.com+1-801-349-2682 > Libvirt virtualization library http://libvirt.org But doesn't Debian's practice create other problems? If I want to write a portable script that calls one of these scripts, I have to call them differently whether I'm on a Debian system or not. (Other workarounds exist, of course, e.g., creating sym-links so either name will work.) And, if the upstream man page correctly references the script with the suffix, when Debian strips the script's suffix, does it also make the corresponding change to the man page? IMHO--but who cares?--the correct thing to do is leave the suffix alone as the author intended, but to lobby for a change in practice. --Ken Nellis
