OK, a mass reply as so many articles arrived on that thread. As Weddington, Eric wrote:
> Joerg, how well would this work on FreeBSD? These changes are only > bash-isms AFAIK, but you know more about unix compatibility issues. Your patch is completely free of any bashism, so it's fine. Ruud's original patch contains just one thing that is not generally applicable (at least from glancing at it -- I didn't try it): the keyword "function" (actually a kshism, to be fair). Just remove that keyword, and you're fine -- seriously, I never understood why Dave Korn introduced that keyword at all. Shell functions have been in use long before the Korn shell (so they are also available in the non-Posix Solaris /bin/sh), but without the need of any keyword to introduce them. Just writing version() { # body of function } does the trick. The only other cosmetic thing I'd like to change is this comment: # Simple version normalizer by Ruud Vlaming (r...@betaresearch.nl) IMHO that's a meta information that rather belongs into the CVS commit message (and into the ChangeLog file then). As Weddington, Eric wrote: > Bah. Attachment error. Trying again. Your mailer sends "application/octet-stream" attachments that are stripped by the mailing list software. Try renaming the patch into something that ends in .txt, I guess that will make your MUA declare it as "text/plain". As Ruud Vlaming wrote: > #! /bin/sh > is not compatible with the function declaration, and should be changed to > #!/bin/bash > I dunno about Free BSD Better just stick with that "dash" shell, which appears to be a version of the Almquist shell. This is essentially the same shell as the one that is used by the 4.4BSD derivatives, and it aims to be a minimal Posix shell, without ending up in creeping featurism as bash does. However, note that Solaris (alas) doesn't ship with a Posix compliant /bin/sh by default. The Solaris shell lacks: . the more esoteric #, ##, %, and %% variable expansion modifiers, use sed or expr instead, and . shell arithmetics, use expr instead. One of the auto* tools (I think it's autoconf) contains a good collection of hints for writing portable shell scripts. /bin/bash is completely unportable, and will most likely only work on Linux systems. (Other systems, even if they offer a bash as an alternative shell, might offer it as /usr/bin/bash or even /usr/local/bin/bash.) /bin/sh is essentiall the only agreed standard name of a shell, but for a Posix-sanctioned way, you'd have to use just a colon as the first line rather than the sheebang (#!) magic. As Weddington, Eric wrote: > > #! /bin/sh > > is not compatible with the function declaration, and should > > be changed to > > #!/bin/bash > What?! If that distro can't handle a little bit of whitespace, then > I'd say that it's broken and doesn't deserve to be supported anyway. It's not the white space but the different name of the shell. OT: Ted Roth once mentioned to me that he's always using the whitespaced version of the sheebang magic: #! /<name of interpreter> rather than #!/<name of interpreter> The reason for that is that there used to be one historical version of Unix that simply interpreted the first four characters "#! /" as a 32-bit "magic" number to decide this is to be handled as an interpreted script rather than a native executable. For any modern Unix-like system, it doesn't really matter. As Ruud Vlaming wrote: > > My eyes glaze over looking at those sed expressions. > > At least the arithmetic comparisons I can understand fairly quickly. > It is a matter of taste i guess, but for most it is certainly a WORN > language: write once, read never ...;-) I know it as "Regular expressions are always write-only items." As Preston Wilson wrote: > I have not kept up with the state of the various command > interpreters, but I suspect that bash is a superset of the POSIX > standard for sh, and that the script is using something that is > specific to bash. Yep, exactly. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list