bug-bash
[Top][All Lists]
Advanced

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

Re: error with ' in command substitution


From: Sven Mascheck
Subject: Re: error with ' in command substitution
Date: 3 Nov 2007 14:21:44 -0000
User-agent: tin/1.8.2-mod ("Elizium") (UNIX)

Stephane Chazelas wrote:
>> According to Scott Moser on 10/30/2007 7:12 AM:

>>> x=$(cat <<"EOF"
>>> bad' syntax
>>> EOF

> Note that it's the same as for 
> 
> $(
>  case a in
>    a) ...
>  esac
> )

These are already on the todo list.  See
<mailman.2318.1177087013.7795.bug-bash@gnu.org>.



> I thought the POSIX
> case a in
>  (a) ...
> esac
> 
> was introduced partly because of that, but I may be wrong as I
> can find no trace of it in the spec.

SUSv3 rationale to shell commands, C.2.9,

 "An optional left parenthesis before pattern was added to allow
  numerous historical KornShell scripts to conform. At one time,
  using the leading parenthesis was required if the case statement
  was to be embedded within a "$()" command substitution; this is no
  longer the case with the POSIX shell. Nevertheless, many historical
  scripts use the left parenthesis, if only because it makes
  matching-parenthesis searching easier in vi and other editors." 



> Anyway, that was just to say that the bug being discussed here
> is also in the other shells: pdksh and its derivatives (posh,
> mksh), ksh88 (so most commercial POSIX sh) and zsh.

Except all ash variants and ksh93 as you mentioned earlier.

I haven't found out yet if this was by intention or by "luck".
But I couldn't discover any problem about $() in ash at all;
even the original ash accepted

echo $(
cat <<\)
    here-doc terminated with a parenthesis
)
)



> I find that bash is probably one of (if not the)
> most compliant (that's the one thing I use bash for).

A comparison with ksh93 would be interesting [1], though, but...

> Compare to ksh88 based sh on commercial Unices
> that still have the same bugs 10 years after.

...a comparison against a shell which isn't actively maintained
anymore doesn't make sense (let alone, that ksh93 could be
called the maintained part).


[1] ...especially because POSIX is quite ksh93 centric, perhaps
more than seems reasonable, sometimes.  A pretty bad example was
in an older rationale, ISO/IEC 9945-2:1993, E.3.6.3, p. 833:

"the author of the KornShell has agreed to make the appropriate
 modifications to do so"

Sven




reply via email to

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