On Sun, 30 Jun 2002, Herbert Xu wrote:
Adam Heath [EMAIL PROTECTED] wrote:
There are minor non-posix issues. The biggest is the use of echo -n(don't
say
use printf, it's too slow for shoop's target audience).
In the current Debian ash package, echo calls the printf builtin
Adam Heath [EMAIL PROTECTED] wrote:
There are minor non-posix issues. The biggest is the use of echo -n(don't say
use printf, it's too slow for shoop's target audience).
In the current Debian ash package, echo calls the printf builtin
internally, and I'm yet to see a slow down.
--
Debian
There are minor non-posix issues. The biggest is the use of echo -n(don't say
use printf, it's too slow for shoop's target audience).
It looks to me like the biggest is the use of 'local', actually.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
On Sat, 22 Jun 2002, Clint Adams wrote:
Any chance of a rerun with posh (sources are in queue/new and readable)
or pdksh?
I don't think you'll be able to gauge posh that way; shoop isn't
POSIX-compliant.
There are minor non-posix issues. The biggest is the use of echo -n(don't say
use
Anthony Towns aj@azure.humbug.org.au wrote:
If it's not to enable backwards and cross-Unix compatability, why do we
care about POSIX at all?
bash, /bin/echo and POSIXLY_CORRECT /bin/echo all treat \c as a literal,
for reference.
GNU has always adopted the BSD behaviour of not interpreting
aj If it's not to enable backwards and cross-Unix compatability, why
aj do we care about POSIX at all?
aj bash, /bin/echo and POSIXLY_CORRECT /bin/echo all treat \c as a
aj literal, for reference.
Herbert GNU has always adopted the BSD behaviour of not interpreting
Herbert back slashes. All
On Fri, Jun 21, 2002 at 01:53:58PM -0400, Joey Hess wrote:
Take shoop benchmarks (this is an old shoop tree I had lying around):
bash: 1000 shoop 1st-stage resolver method calls : 0:05.51
ash : 1000 shoop 1st-stage resolver method calls : 0:01.33
bash: 1000
On Fri, Jun 21, 2002 at 06:05:39PM -0400, Clint Adams wrote:
sake. I understand the alleged benefits of ash (small, loads faster on a
slow/small memory machine). Why would I, Debian user, benefit from being
able to run pdksh as /bin/sh? (Remembering that standards compliance, in
and of
Any chance of a rerun with posh (sources are in queue/new and readable)
or pdksh?
I don't think you'll be able to gauge posh that way; shoop isn't
POSIX-compliant.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
As far as I can tell there are two possibilities here:
(a) it is pdksh or posh, and it already works at least as well
as ash on the various #!/bin/sh scripts in Debian, or
It is pdksh.
(b) it is pdksh or posh or similar, and it doesn't yet work as
well as
Branden == Branden Robinson [EMAIL PROTECTED] writes:
Branden If:
Branden * Release critical bugs are _very_ rare.; and
Branden * Release critical bugs should be the domain of the Release Manager,
Branden Then we really don't need a tight connection between the
Branden serious severity and
On Sat, Jun 22, 2002 at 02:02:00AM -0500, Manoj Srivastava wrote:
Branden == Branden Robinson [EMAIL PROTECTED] writes:
Branden * Release critical bugs are _very_ rare.; and
Branden * Release critical bugs should be the domain of the Release Manager,
Branden Then we really don't need a
On Sat, Jun 22, 2002 at 09:29:42PM +1000, Anthony Towns wrote:
Sorry, but this doesn't follow. Treating serious as a severity or a
tag is largely immaterial, and the fundamental point of the serious
severity or tag is as an aid to release management.
That may be its intent, but apparently
9989 * An alias shall be written as a
command line that represents its alias definition.
cf. alias:
| The following operands shall be supported:
|
| alias-name
| Write the alias definition to standard output.
[...]
| The format for displaying aliases
On Thu, Jun 20, 2002 at 11:31:42PM -0400, Clint Adams wrote:
Having echo aliased to `printf %s\n $*' would give you better POSIX
compliance too.
No, in fact, it would not.
Compare the output of
ash -c 'echo test\c'
versus
printf %s\n test\c
Ah, I see. So, POSIX recognises that there are
Ah, I see. So, POSIX recognises that there are two distinct traditional
behaviours, then specifies something that's specifically incompatible with
both of them, and the GNU utilities?
No, it's specifically compatible with SysV echo.
If it's not to enable backwards and cross-Unix
On Fri, Jun 21, 2002 at 12:05:38AM -0400, Clint Adams wrote:
9989 * An alias shall be written as a
command line that represents its alias definition.
cf. alias:
| The following operands shall be supported:
|
| alias-name
| Write the alias
On Fri, Jun 21, 2002 at 03:09:17AM -0400, Clint Adams wrote:
That, however, isn't the question being discussed. The question is whether
I'm going to *support* them in doing so: fix problems that wouldn't have
existed if they hadn't done so, or avoid creating them in the first place.
Well,
On Thu, Jun 20, 2002 at 11:31:42PM -0400, Clint Adams wrote:
Unless policy is changed, indications are that the only packages using
command -v by the time of woody+1's release will be XFree86.
Easy now. I don't *like* the construction
if command -v foo /dev/null 21; then
foo
fi
I hate
On Fri, Jun 21, 2002 at 02:49:00PM +1000, Anthony Towns wrote:
If you can't justify a change without reference to policy, then you
shouldn't be suggesting it,
!?
No more wishlist bugs?
--
G. Branden Robinson|I've made up my mind. Don't try to
Debian GNU/Linux
On Fri, Jun 21, 2002 at 03:09:17AM -0400, Clint Adams wrote:
I didn't realize that policy compliance was some sort of buddy-boy
system.
/me watches comprehension slowly, slowly wash over Clint's
countenance...
--
G. Branden Robinson| It doesn't matter what you are
Debian
Branden Robinson [EMAIL PROTECTED] writes:
On Fri, Jun 21, 2002 at 02:49:00PM +1000, Anthony Towns wrote:
If you can't justify a change without reference to policy, then you
shouldn't be suggesting it,
!?
No more wishlist bugs?
Perhaps a rephrase would help?
If the _only_
On Sat, Jun 22, 2002 at 01:13:47AM +1000, Anthony Towns wrote:
Then please, pay attention. I've explained this a dozen times on this
list already, so if you need a different wording surely there's someone
out there how can provide it.
Release critical bugs are _very_ rare. They're not for
Anthony Towns wrote:
I haven't been able to observe any speed differences between ash and bash,
so I don't expect I'd see any anywhere else. If you've got something
where there's an observable improvement in speed in using some other
shell compared to both ash and bash, I'd be interested.
Easy now. I don't *like* the construction
if command -v foo /dev/null 21; then
foo
fi
I hate that nasty redirection that is imposed on me.
Well, the popular proposal (which seems to be SUSv3+UP+XSI), will give
you type, and you'll need to redirect that as well.
If you want some sort
If this is regarding the [ -a -o ] stuff, then sorry, but debhelper is just
the tip of the iceberg, or at least of my personal iceberg.
Hmm.. I must have grepped badly.
There will be tens of thousands in all of debian, if this sample of 100
packages is representative. I even find them in
I know I'm going to hate getting into this one, but:
On 21-Jun-02, 14:31 (CDT), Clint Adams [EMAIL PROTECTED] wrote:
(2) There's no benefit to anyone using a shell other than ash or
bash as /bin/sh on a Debian system.
No, you're being deliberately obtuse on this one.
Clint,
sake. I understand the alleged benefits of ash (small, loads faster on a
slow/small memory machine). Why would I, Debian user, benefit from being
able to run pdksh as /bin/sh? (Remembering that standards compliance, in
and of itself, does not give me a sexual thrill.)
I answered this
On Wed, Jun 19, 2002 at 02:34:30AM -0400, Clint Adams wrote:
The exact output of command -v is not given by POSIX.
I believe it says
When the -v option is specified, standard output shall be formatted as:
%s\n, pathname or command
Are you referring to the extra new line that ash
On Wed, Jun 19, 2002 at 02:05:01PM -0400, Clint Adams wrote:
Scenario A: Script works on bash and ash, which are the two main shells
anyone
has a reason to use as /bin/sh on Debian.
Scenario B: Script works on bash and ash, which are the two main shells
anyone
has a reason to use
Are you referring to the extra new line that ash outputs after an alias?
If so that is indeed incorrect and will be fixed.
I also interpret the leading literal alias to be incorrect. It's
less useful, at any rate.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
I don't really care whether it should or shouldn't be so, but it certainly
seems like it *is* so. Using bash minimises the disk space used by shells
and is the most reliable, and using ash is faster. Are there any other
benefits to be had by using different shells?
Using pdksh will give you
On Thu, Jun 20, 2002 at 08:24:21AM -0400, Clint Adams wrote:
Are you referring to the extra new line that ash outputs after an alias?
If so that is indeed incorrect and will be fixed.
I also interpret the leading literal alias to be incorrect. It's
less useful, at any rate.
In the case
In the case of command -v, the alias prefix is required.
Reference?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Thu, Jun 20, 2002 at 11:32:34PM -0400, Clint Adams wrote:
In the case of command -v, the alias prefix is required.
Reference?
9989 * An alias shall be written as a
command line that represents its alias definition.
--
Debian GNU/Linux 2.2 is out! (
On Tue, Jun 18, 2002 at 03:56:12AM -0400, Clint Adams wrote:
I'd be happy with SUSv3, UP relevant to non-interactive use, and the
appropriate subset of XSI. Of course, you realize that this reverses
the 'echo -n' exception and that people will cry.
I have nothing against keeping the echo -n
Clint Adams [EMAIL PROTECTED] wrote:
Apparently due to sleep-deprivation, I confused Herbert's assertion with
fact. It's set -h that's forbidden. Debian does not need XSI for set -e.
I appologise for this incorrect assertion. I had misread the canonical
form of set. set -e is indeed
On Wed, Jun 19, 2002 at 02:00:36AM -0400, Clint Adams wrote:
Please be more specific.
ash:
does not handle multiple heredocs
Thanks, this will be fixed.
read-write fd's do not behave usefully[1]
Not specified by POSIX.
treats $10 as ${1}0
Forbidden by POSIX:
1358
2. There are some features which are regularly used in maintainer
and other scripts which depend on them, e.g.,
the options -a and -o, as well as parentheses for the
test command or [.
the obsolescent forms of kill and trap: kill -INT or kill -9.
I've already filed some
On Wed, Jun 19, 2002 at 02:26:35AM -0400, Clint Adams wrote:
I've already filed some bugs on 'trap'-misusing packages.
test -a, -o, and parentheses could easily be replaced by and-or listse
Sure, so could command -v. The problem is with the amount of scripts
that use them.
--
Debian
Forbidden by POSIX:
I see. I'll correct the test.
The exact output of command -v is not given by POSIX.
I believe it says
When the -v option is specified, standard output shall be formatted as:
%s\n, pathname or command
Am I looking in the wrong place?
More details please.
%s=%s\n,
I'm surprised by how many package scripts use kill, but the number is
not excessive.
On the other hand, no one seems to want to fix these. Instead of a
one-line fix, histrionics, bug-closings, and references to Solaris seem
to be in order.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
On Wed, Jun 19, 2002 at 05:20:19AM -0400, Clint Adams wrote:
I'm surprised by how many package scripts use kill, but the number is
not excessive.
On the other hand, no one seems to want to fix these.
Imagine, people actually wanting a justification beyond random document
X says so for bugs
Imagine, people actually wanting a justification beyond random document
X says so for bugs filed at a serious severity.
How about I litter all my #!/bin/sh postinsts with useless zshisms?
Then when people file bugs, I say Haha, fuck you; it works for me.
debian-policy -- says you should do
On Wed, Jun 19, 2002 at 07:59:33AM -0400, Clint Adams wrote:
Imagine, people actually wanting a justification beyond random document
X says so for bugs filed at a serious severity.
How about I litter all my #!/bin/sh postinsts with useless zshisms?
How about we add I'm not such an idiot to
Scenario A: Script works on bash and ash, which are the two main shells anyone
has a reason to use as /bin/sh on Debian.
Scenario B: Script works on bash and ash, which are the two main shells anyone
has a reason to use as /bin/sh on Debian.
Why on earth should this be so? Is saying The
Steve == Steve Greenland [EMAIL PROTECTED] writes:
Steve I wasn't discussing any particular command, and Manoj didn't
Steve mention the FHS. I think if we (Debian) said Early running
Steve init scripts can count on the FHS required commands being in
Steve /bin:/sbin, and anything else might be
Moshe == Moshe Zadka [EMAIL PROTECTED] writes:
Moshe I may be just stupid,
;-)
Moshe but what does /usrness[1] have to do with embedded systems?
Moshe After all, if the embedded system has no disk space for (say)
If you disallow things like this by axiom, you can prove
Steve == Steve Greenland [EMAIL PROTECTED] writes:
Steve On 16-Jun-02, 22:04 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote:
Having an explicit, separate documentation of technical things
that has to be maintained, or else it slips out of synchronization
with reality, is certainly not to
I do not see why we should use which. As I have stated previously, we
already require feature sets (set -e in particular) in the new POSIX
document which imply the existence of type(1). So type should be
Can we codify this better?
the preferred utility for this task. Besides, as an
On Tue, Jun 18, 2002 at 01:00:25AM -0400, Clint Adams wrote:
This depends on the user's perspective. I can't imagine ever wanting to
do anything other than 'test -x /absolute/path' in a postinst.
I can. I just want to know if the command is available for my script to
use; I don't care about
On Tue, Jun 18, 2002 at 01:00:25AM -0400, Clint Adams wrote:
I do not see why we should use which. As I have stated previously, we
already require feature sets (set -e in particular) in the new POSIX
document which imply the existence of type(1). So type should be
Can we codify this
Clint == Clint Adams [EMAIL PROTECTED] writes:
I do not see why we should use which. As I have stated previously, we
already require feature sets (set -e in particular) in the new POSIX
document which imply the existence of type(1). So type should be
Clint Can we codify this better?
I can. I just want to know if the command is available for my script to
use; I don't care about the latest flamewar that moved it in or out of
/usr or */sbin.
You are searching for a particular word, and that word may represent
a binary/script, a shell function, a shell alias, a shell
I would also support the addition of UP since all the POSIX shells in
Debian support it with the exception of ash which does not currently
support history. Since history support is unlikely to affect scripting,
it would be acceptable for us to specify UP as well as XSI.
I'd be happy with
On Tue, Jun 18, 2002 at 03:50:23AM -0400, Clint Adams wrote:
(F) /usr/bin/which deathrampage 2/dev/null command deathrampage
Advantages: will find and execute deathrampage on the command search path.
Disadvantages: requires faith in /usr/bin/which not moving or changing
(H)
Codify what, please? I personally use which, since it is
provided by am essential package, and I can live with it eing an
external program, and missing aliases. People can also use POSIX type
You don't have that with zsh, since which is a builtin.
(umm, does zsh have type?). Why
The irony is that the only reason to use which is to accomodate speed
freaks who want to be able to use non-bash shells. Now they get hit
by the bash startup time anyway. And those same speed freaks are
likely to be using ash, which has both type and command -v.
I believe that Herbert's
Clint == Clint Adams [EMAIL PROTECTED] writes:
Clint (A) deathrampage || echo uh-oh, continuing without it
Clint Advantages: portable
Clint Disadvantages: requires running the program in question
But if you doi want to run it, this is it,, end of story. So,
now for when we want to
But if you doi want to run it, this is it,, end of story. So,
now for when we want to merely test for presence.
Perhaps if you want to test for multiple commands before executing them?
So what? Who the hell is the postinst to tell me what I should
or should not be doing with my
Clint == Clint Adams [EMAIL PROTECTED] writes:
Codify what, please? I personally use which, since it is
provided by am essential package, and I can live with it eing an
external program, and missing aliases. People can also use POSIX type
Clint You don't have that with zsh, since which is
I don't have what? which is present, either as a builtin, or
provided by an essential package. What exactly do I not have?
You don't have a standard interface. Any POSIX-compliant shell could
easily implement a 'which' builtin that returns success no matter what.
This would not violate
Clint == Clint Adams [EMAIL PROTECTED] writes:
But if you doi want to run it, this is it,, end of story. So,
now for when we want to merely test for presence.
Clint Perhaps if you want to test for multiple commands before
Clint executing them?
Umm, say what? You mean you want to
Umm, say what? You mean you want to test for presence of
multiple commands and execute one or more? (not something you covered
origiannly, but in that case go to case H
I'm hypothesizing. I can think of no real-world examples where I'd need
to do anything fancy here.
And what
On Tue, Jun 18, 2002 at 04:18:58AM -0400, Clint Adams wrote:
I once again recommend a deathmatch between ash and zsh fans. Let
the best shell win.
bash doesn't even get to compete?
bash is sitting contentedly in a corner, with a smug smile that says
I am the default /bin/sh and you know
On Tue, Jun 18, 2002 at 03:50:23AM -0400, Clint Adams wrote:
(D) command -v deathrampage 2/dev/null deathrampage
OR type deathrampage 2/dev/null deathrampage
Advantages: will find and execute deathrampage anywhere
Disadvantages: will find and execute deathrampage anywhere, no matter if
How are we to prevent this anyway? Who says any of the other solutions can't
be botched like this?
The difference is that I, as a user, would never expect for a postinst
to look for something called deathrampage, and by extension, would never
expect for a postinst to suddenly be running the
On Tue, Jun 18, 2002 at 06:02:08AM -0400, Clint Adams wrote:
How are we to prevent this anyway? Who says any of the other solutions can't
be botched like this?
The difference is that I, as a user, would never expect for a postinst
to look for something called deathrampage, and by
On Tue, Jun 18, 2002 at 06:11:00AM -0400, Clint Adams wrote:
What if the user puts tripwire or some other nice English word in the
path, not knowing this is also a command in Debian? It's really hard to
account for any of these weird scenarios...
What if? I also wouldn't expect, nor
Josip == Josip Rodin [EMAIL PROTECTED] writes:
Josip What if the user puts tripwire or some other nice English word in the
Josip path, not knowing this is also a command in Debian? It's really hard to
Josip account for any of these weird scenarios...
If the user has put soemthing in
Clint == Clint Adams [EMAIL PROTECTED] writes:
I don't have what? which is present, either as a builtin, or
provided by an essential package. What exactly do I not have?
Clint You don't have a standard interface. Any POSIX-compliant
Clint shell could easily implement a 'which' builtin
Clint == Clint Adams [EMAIL PROTECTED] writes:
How are we to prevent this anyway? Who says any of the other
solutions can't be botched like this?
Clint The difference is that I, as a user, would never expect for a
Clint postinst to look for something called deathrampage, and by
Clint
Clint == Clint Adams [EMAIL PROTECTED] writes:
What if the user puts tripwire or some other nice English word in the
path, not knowing this is also a command in Debian? It's really hard to
account for any of these weird scenarios...
Clint What if? I also wouldn't expect, nor want, to
Notice or some other nice English word... when the admin puts binaries in
a $PATH, they need to be aware of the consequences. If they put something in
a place where it can replace a Debian binary, how do we know it's
Why would someone, being told that '/usr/local is for the administrator;
Is POSIX + extention.
How is this relevant?
Yes, it does. There are never going to be no problems.
Oh, I see your logic. Therefore, we should never solve any problems.
Unlikely. The best you'll get it POSIX+extention, and that
still means command -v is a bashism.
So why are you putting something in roots path ahead of the
standard path unless you want it to be run?
Under what circumstances? In which context? root has different paths
at different times.
I think that is a bug.
I think that is a feature.
--
To UNSUBSCRIBE, email to
On 17-Jun-02, 21:51 (CDT), Anthony Towns aj@azure.humbug.org.au wrote:
It seems sloppy is a pretty poor argument for moving every binary not
specifically mentioned in the FHS into /usr and gratuitously breaking
any scripts that needed them where they are.
Yes, that would be a pretty poor
On Tue, Jun 18, 2002 at 07:58:21AM -0400, Clint Adams wrote:
Notice or some other nice English word... when the admin puts binaries in
a $PATH, they need to be aware of the consequences. If they put something in
a place where it can replace a Debian binary, how do we know it's
Why would
On Tue, Jun 18, 2002 at 07:58:21AM -0400, Clint Adams wrote:
Notice or some other nice English word... when the admin puts binaries in
a $PATH, they need to be aware of the consequences. If they put something in
a place where it can replace a Debian binary, how do we know it's
Why would
On Tue, Jun 18, 2002 at 03:56:12AM -0400, Clint Adams wrote:
I would also support the addition of UP since all the POSIX shells in
Debian support it with the exception of ash which does not currently
support history. Since history support is unlikely to affect scripting,
it would be
Richard Braakman wrote:
The irony is that the only reason to use which is to accomodate speed
freaks who want to be able to use non-bash shells. Now they get hit
Or wackos who code using tcsh. :) (yes, i know about the csh programming
considered harmful. I guess I'll just use perl instead.)
Clint == Clint Adams [EMAIL PROTECTED] writes:
Clint Why would someone, being told that '/usr/local is for the
Clint administrator; Debian doesn't touch it' assume that package
Clint scripts will go around running things in /usr/local?
The scripts should not, and this is why hard
Josip == Josip Rodin [EMAIL PROTECTED] writes:
Josip Notice or some other nice English word... when the admin
Josip puts binaries in a $PATH, they need to be aware of the
Josip consequences. If they put something in a place where it can
Josip replace a Debian binary, how do we know it's
Clint == Clint Adams [EMAIL PROTECTED] writes:
So why are you putting something in roots path ahead of the
standard path unless you want it to be run?
Clint Under what circumstances? In which context? root has different paths
Clint at different times.
Are you being delibrately
Clint == Clint Adams [EMAIL PROTECTED] writes:
Is POSIX + extention.
Clint How is this relevant?
Yes, it does. There are never going to be no problems.
Clint Oh, I see your logic. Therefore, we should never solve any problems.
Managing to rember context does not seem to be your
Steve == Steve Greenland [EMAIL PROTECTED] writes:
Steve I don't. However, we already have cases of specific developers being,
Steve shall we say, difficult. Not sloppy, but having very strong opinions
Steve about how a particular thing should be done, despite a large number of
Steve other
On Tue, Jun 18, 2002 at 05:14:23AM -0400, Clint Adams wrote:
Apparently if you have zsh as /bin/sh and try to install xdm, the
postinst will happily tell you what version of debianutils to install to
get readlink.
?
First I've heard of this. What's going on?
Oh, I know.
if ! command -v
Manoj and you are the one who came up with the pie in the
Manoj sky ``when there are no problems''.
Manoj Since you manage to forget context from message to message, I
Manoj guess it makes a weird kind of sense that now you attribute
Manoj statements like the above to your opponents.
No, Manoj,
On Tue, Jun 18, 2002 at 10:51:27AM -0500, Manoj Srivastava wrote:
Josip Notice or some other nice English word... when the admin
Josip puts binaries in a $PATH, they need to be aware of the
Josip consequences. If they put something in a place where it can
Josip replace a Debian binary, how
The scripts should not, and this is why hard codiong paths is
a bug.
A policy violation, or just a bug?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
XSI.
IEEE Std 1003.1-2001 describes utilities, functions, and facilities
offered to application programs by the X/Open System Interface (XSI).
Functionality marked XSI is also an extension to the ISO C
standard. Application writers may confidently make use of an
extension on all
Yeah, well, I'll be happy to change this once we have some official
Policy, or an offical Best Current Practice statement.
We DO have an official Policy. It makes 'command -v' unusable in
#!/bin/sh scripts. That's 688 packages in violation. It makes 'set -e'
unusable in #!/bin/sh scripts.
Clint == Clint Adams [EMAIL PROTECTED] writes:
Yeah, well, I'll be happy to change this once we have some official
Policy, or an offical Best Current Practice statement.
Clint We DO have an official Policy. It makes 'command -v' unusable in
!/bin/sh scripts. That's 688 packages in
Hi,
Clint == Clint Adams [EMAIL PROTECTED] writes:
Yeah, well, I'll be happy to change this once we have some official
Policy, or an offical Best Current Practice statement.
Clint It makes 'set -e' unusable in #!/bin/sh scripts.
Umm, could you explain why this is so?
manoj
Ian == Ian Zimmerman [EMAIL PROTECTED] writes:
Manoj Since you manage to forget context from message to message, I
Manoj guess it makes a weird kind of sense that now you attribute
Manoj statements like the above to your opponents.
Ian No, Manoj, it's you who missed the context here.
Clint == Clint Adams [EMAIL PROTECTED] writes:
Clint Are you suggesting that Debian support this extension, or a subset
Clint thereof?
Ah. Before I provide my impramatur of approval over words that
shall be writ in stone, are there any shells that have POSIX+XSI
On Tue, Jun 18, 2002 at 07:58:21AM -0400, Clint Adams wrote:
Notice or some other nice English word... when the admin puts binaries in
a $PATH, they need to be aware of the consequences. If they put something in
a place where it can replace a Debian binary, how do we know it's
Why would
The policy explicitly mentions that set -e is to be used. Have
we collectively taken leave of common sense?
No, it mentions that set -e SHOULD be used in some cases. The fact that
it mentions /bin/sh in context with 'set -e' might be a bit confusing,
but I don't think that that
Clint == Clint Adams [EMAIL PROTECTED] writes:
The policy explicitly mentions that set -e is to be used. Have
we collectively taken leave of common sense?
Clint No, it mentions that set -e SHOULD be used in some cases. The fact that
Clint it mentions /bin/sh in context with 'set -e' might
Ah. Before I provide my impramatur of approval over words that
shall be writ in stone, are there any shells that have POSIX+XSI
extensions+UP-in-interactive-mode? If so, this could be a useful
criteria. If there are no such shells, well, we live with what we
have, and reassess when
1 - 100 of 142 matches
Mail list logo
