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
> 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? Con
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
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
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.
Anthony Towns 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 back
slashes. All
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 apparentl
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
On Sat, Jun 22, 2002 at 03:06:38AM -0400, Clint Adams wrote:
> > 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
>>"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
> 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
>
> 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]
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
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: 1
> 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 expli
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.
C
> 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
> Easy now. I don't *like* the construction
>
> if command -v foo > /dev/null 2>&1; 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
> Yeesh. I don't know what so hard about this. The following statements are
> true.
>
> I am not an idiot.
> I do not need to be forced to follow good advice.
> Policy is by and large good advice.
The preceding three statements are subjective. I think it's good advice
for the X
Clint Adams wrote:
> > For the latter, you're yet to show *any* practical utility in using other
> > shells -- and indeed you've demonstrated some reasons why you would *not*
> > want to use other shsels, and you've already shown that we've got a fair
> > way to go before we do support them.
>
> I
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 shell> compared to both ash and bash, I'd be interested.
Take shoop
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 fo
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 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
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 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 2>&1; then
foo
fi
I ha
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.
>
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 ali
> 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 compatabi
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 recognis
> 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: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!
> 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]
> 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"
> There's a reason why we specifically *don't* do that.
You mean, other than the fact it won't wor
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 t
On Thu, Jun 20, 2002 at 10:42:15AM -0400, Clint Adams wrote:
> > 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
> > be
> 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 yo
> 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 "unsubscr
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 r
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",
Are you referring to the extra new line that ash outputs after
> 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 "T
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 i
> 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 shou
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" fo
> 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
> Sure, so could command -v. The problem is with the amount of scripts
> that use them.
Once most packages are recompiled with newer debhelper, the command -v
problem should pretty much disappear with the exception of of Branden's
packages.
I've already received positive feedback on most of the
> 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",
Am I looking in the wrong place?
> More details please.
"%s=%s\n", name, value
--
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 GNU/L
> 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: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
> Please be more specific.
ash:
does not handle multiple heredocs
read-write fd's do not behave usefully[1]
treats $10 as ${1}0
does not support cd -L
does not support cd -P
echo -n
incorrect output for command -v
incorrect output for alias
POSIX-mode bash:
echo -n
incorrect output for command
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 spe
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
Clint Adams wrote:
experiences problems due to their choice of /bin/sh should be
ridiculed by histrionic demagogues until they can display a
modicum of common sense by writing a /bin/sensible-sh wrapper
that attempts to find the most suitable shell for the job.
Perhaps M
Clint Adams wrote:
> That's 688 packages in violation. It makes 'set -e'
unusable in #!/bin/sh scripts. That's 6810 packages in violation.
At least 7498 packages in sid have preinsts, prerms, postinsts, or postrms
which violate Debian policy.
Put the crackpipe down, and read:
"The package ma
>>"Clint" == Clint Adams <[EMAIL PROTECTED]> writes:
>> 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 shell
>>"Clint" == Clint Adams <[EMAIL PROTECTED]> writes:
>> Historical reasons.
Clint> Ah, so then in that case, it makes sense to require 'echo -n' from
Clint> /bin/sh, while forbidding it in /bin/sh scripts as part of a migration
Clint> strategy.
I would have no problemwith such a pro
> Look for the -e option for the set utility.
Yes, yes.
> Historical reasons.
Ah, so then in that case, it makes sense to require 'echo -n' from
/bin/sh, while forbidding it in /bin/sh scripts as part of a migration
strategy.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a s
> Back it up, buddy. Where is your proof? I have given three
> explicit references from policy strongly recommending set -e. Where
> the heck is it forbidden?
Apparently due to sleep-deprivation, I confused Herbert's assertion with
fact. It's set -h that's forbidden. Debian does not nee
>>"Clint" == Clint Adams <[EMAIL PROTECTED]> writes:
Clint>> It makes 'set -e' unusable in #!/bin/sh scripts.
Manoj>> Umm, could you explain why this is so?
Clint> I think it is reasonable to assume that "POSIX features" and "non-POSIX
Clint> features" translate to those which are and are not
> 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 w
>>"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 'se
> Umm, could you explain why this is so?
I think it is reasonable to assume that "POSIX features" and "non-POSIX
features" translate to those which are and are not mandated by the
current POSIX standard.
Thus, shell scripts specifying `/bin/sh' as interpreter should only
use POSIX
> 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 overrid
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
>
> Wh
>>"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
extensions+UP-
>>"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
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?
>>"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 packa
> 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.
> 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
> 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]
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 bi
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, Ma
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 r
On Tue, Jun 18, 2002 at 08:13:19AM -0500, Steve Greenland wrote:
> On 17-Jun-02, 21:51 (CDT), Anthony Towns 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
>>"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
Stev
>>"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
>>"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 d
>>"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 h
>>"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
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.)
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 b
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 w
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
>
> Wh
On 17-Jun-02, 21:51 (CDT), Anthony Towns 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 argument, if I had
> 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 [
> 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.
D
> 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;
>>"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, no
>>"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'
>>"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
>>"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 soem
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,
> 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 want, to have Debian package scripts
trying to execute some random
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 ext
> 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 'd
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 ma
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
> 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 wh
1 - 100 of 155 matches
Mail list logo
