I think that the major culprit will be {} expansion constructs, as in
{tmp-a,tmp-b}/*.c
In lack of a more ambitious appendix, at least this example should be
included in the policy manual.
---+--
Christian Lynbech
> On Tue, Jan 13, 1998 at 11:34:21PM +0100, Christian Schwarz wrote:
> > Restrict your script to POSIX features when possible so that it may
> > use /bin/sh as its interpreter. If your script works with ash, it's
> > probably POSIX compliant, but if you are in doubt, use /bin/bash.
>
On Wed, Jan 14, 1998 at 02:50:39PM +0100, Christian Schwarz wrote:
> On Wed, 14 Jan 1998 [EMAIL PROTECTED] wrote:
>
> > On Tue, Jan 13, 1998 at 11:34:21PM +0100, Christian Schwarz wrote:
> > > Restrict your script to POSIX features when possible so that it may
> > > use /bin/sh as its in
On Wed, 14 Jan 1998 [EMAIL PROTECTED] wrote:
> On Tue, Jan 13, 1998 at 11:34:21PM +0100, Christian Schwarz wrote:
> > Restrict your script to POSIX features when possible so that it may
> > use /bin/sh as its interpreter. If your script works with ash, it's
> > probably POSIX compli
On Tue, Jan 13, 1998 at 11:34:21PM +0100, Christian Schwarz wrote:
> Restrict your script to POSIX features when possible so that it may
> use /bin/sh as its interpreter. If your script works with ash, it's
> probably POSIX compliant, but if you are in doubt, use /bin/bash.
I'd pref
[This mail is part of Debian Policy Weekly issue #5]
Topic 1: Bash vs Bourne shell
STATE: APPROVAL
There has been a long discussion on debian-policy about which shell features
can be assumed to be provided by /bin/sh. Currently, a lot of packages use
bash-specific features but specify "#!/bin/s
6 matches
Mail list logo
