[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

From: Joerg Wunsch
Subject: Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in
Date: Fri, 30 Jan 2009 22:01:18 +0100
User-agent: Mutt/1.5.11

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

   # 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 (address@hidden)

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

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. ;-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]