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
>>"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 y
> 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:
>> 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, si
> 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
>>"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 w
> 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 Herbe
> 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
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) #!/bin/
> 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
> 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 built
>>"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
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 t
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
> 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 ext
61 matches
Mail list logo
