FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 12-12-2007, 04:02 AM
Ralf Corsepius
 
Default Stupid bash question

On Tue, 2007-12-11 at 23:26 -0500, Joe Smith wrote:
> Tony Nelson wrote:
> > The reason seems weak to me, but test does not require a closing
> > square bracket, while [ does, and:
> > ...
> >> GNU Coding Standards now declare that the behaviour of binary
> >> should not depend on its name.
>
> From http://www.gnu.org/prep/standards/html_node/User-Interfaces.html:
> > Please don't make the behavior of a utility depend on the name used to
> > invoke it. It is useful sometimes to make a link to a utility with a
> > different name, and that should not change what it does.
>
> Sounds more like a request than a declaration ;-)
>
> I wish they had provided some rationale,
It's simplicity and usage-safety.

> seeing as how the practice has
> a long history on Unix,
Right, some (actually very few) packages apply this working principle.

> and I (at least) have not run into any situation
> where it caused a problem.
It would be quite easy to provoke:

Assume a program to change its behavior depending on whether it's called
"X", "Y" or "Z". Now rename it to "A" or try to use copy of X under the
name "myX".

Which behavior will "A" or "myX" expose? The results will be random.


IMO, the fact you haven't seen such effects only is the result of only
very few programs applying "change behavior upon program name"

> Requiring the closing bracket or not seems like a trivial difference in
> behavior, no?
>
> Yep, I'll go with 'weak' as well.
>
> Over a few hundred systems, this must be wasting almost a penny's worth
> of space.

... until people notice that they hardly ever use an external
test-binary but are almost always using a shell's builtin, instead

Ralf


--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-12-2007, 04:07 AM
Les Mikesell
 
Default Stupid bash question

Joe Smith wrote:

Tony Nelson wrote:
> The reason seems weak to me, but test does not require a closing
> square bracket, while [ does, and:
> ...
>> GNU Coding Standards now declare that the behaviour of binary
>> should not depend on its name.

From http://www.gnu.org/prep/standards/html_node/User-Interfaces.html:

Please don't make the behavior of a utility depend on the name used to
invoke it. It is useful sometimes to make a link to a utility with a
different name, and that should not change what it does.


Sounds more like a request than a declaration ;-)

I wish they had provided some rationale, seeing as how the practice has
a long history on Unix, and I (at least) have not run into any situation
where it caused a problem.


And there are good reasons for it. /bin/[ vs. /bin/test are probably
extremely rarely used since the shell built-in takes precedence unless
you specify the path explictly, but cp/ln/mv traditionally were hard
links, saving not only disk space but loading time and RAM when they are
mapped from the same inode.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-12-2007, 04:29 AM
"Dean S. Messing"
 
Default Stupid bash question

Tony Nelson writes:
: The reason seems weak to me, but test does not require a closing square
: bracket, while [ does, and:
:
: At 6:22 PM +0200 5/11/07, Stepan Kasal wrote:
: >Hi,
: >
: >On Fri, May 11, 2007 at 04:44:39PM +0200, Matthias Saou wrote:
: >> single square brackets, I thought "[" was a symlink to the
: >> coreutils "test" command, [..]
: >
: >AFAIK, it used to be hard link, not symlink.
: >
: >> -rwxr-xr-x 1 root root 32168 Apr 17 13:48 /usr/bin/[
: >> -rwxr-xr-x 1 root root 29544 Apr 17 13:48 /usr/bin/test
: >
: >GNU Coding Standards now declare that the behaviour of binary
: >should not depend on its name.

The new coding standards put quite a crimp in the use of
/sbin/busybox, /sbin/lvm, and a lot of other useful linux modules, I
would think.

What's the rationale behind this standard? I've written several
useful pieces of signal processing code whose behaviour depends on the
name one uses to call it. Now, self-modifying code---that I can
understand. :-)

Dean

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-12-2007, 05:37 AM
Ralf Corsepius
 
Default Stupid bash question

On Tue, 2007-12-11 at 21:29 -0800, Dean S. Messing wrote:
> Tony Nelson writes:
> : The reason seems weak to me, but test does not require a closing square
> : bracket, while [ does, and:
> :
> : At 6:22 PM +0200 5/11/07, Stepan Kasal wrote:
> : >Hi,
> : >
> : >On Fri, May 11, 2007 at 04:44:39PM +0200, Matthias Saou wrote:
> : >> single square brackets, I thought "[" was a symlink to the
> : >> coreutils "test" command, [..]
> : >
> : >AFAIK, it used to be hard link, not symlink.
> : >
> : >> -rwxr-xr-x 1 root root 32168 Apr 17 13:48 /usr/bin/[
> : >> -rwxr-xr-x 1 root root 29544 Apr 17 13:48 /usr/bin/test
> : >
> : >GNU Coding Standards now declare that the behaviour of binary
> : >should not depend on its name.
>
> The new coding standards

New? Even version 1.1 of GNU standards (Sun Mar 8 06:28:22 1992 UTC (15
years, 9 months ago)) carries this rule:

http://cvs.savannah.gnu.org/viewvc/gnustandards/standards.texi?revision=1.1&root=gnustandards&view =markup

> put quite a crimp in the use of
> /sbin/busybox, /sbin/lvm, and a lot of other useful linux modules, I
> would think.
>
> What's the rationale behind this standard?

>From [1]
<cite>
@node Preface
@chapter About the GNU Coding Standards

The GNU Coding Standards were written by Richard Stallman and other GNU
Project volunteers. Their purpose is to make the GNU system clean,
consistent, and easy to install. This document can also be read as a
guide to writing portable, robust and reliable programs. It focuses on
programs written in C, but many of the rules and principles are useful
even if you write in another programming language. The rules often
state reasons for writing in a certain way.
</cite>

> I've written several
> useful pieces of signal processing code whose behaviour depends on the
> name one uses to call it. Now, self-modifying code---that I can
> understand. :-)

>From [1]
<cite>
@cindex program name and its behavior
@cindex behavior, dependent on program's name
Please don't make the behavior of a utility depend on the name used
to invoke it. It is useful sometimes to make a link to a utility
with a different name, and that should not change what it does.

Instead, use a run time option or a compilation switch or both
to select among the alternate behaviors.
</cite>

Ralf
[1] http://cvs.savannah.gnu.org/viewvc/gnustandards/gnustandards/standards.texi


--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-12-2007, 07:01 AM
"Dean S. Messing"
 
Default Stupid bash question

Ralf Corsepius wrote:
: On Tue, 2007-12-11 at 21:29 -0800, Dean S. Messing wrote:
: > Tony Nelson writes:
: > : The reason seems weak to me, but test does not require a closing square
: > : bracket, while [ does, and:
: > :
: > : At 6:22 PM +0200 5/11/07, Stepan Kasal wrote:
: > : >Hi,
: > : >
: > : >On Fri, May 11, 2007 at 04:44:39PM +0200, Matthias Saou wrote:
: > : >> single square brackets, I thought "[" was a symlink to the
: > : >> coreutils "test" command, [..]
: > : >
: > : >AFAIK, it used to be hard link, not symlink.
: > : >
: > : >> -rwxr-xr-x 1 root root 32168 Apr 17 13:48 /usr/bin/[
: > : >> -rwxr-xr-x 1 root root 29544 Apr 17 13:48 /usr/bin/test
: > : >
: > : >GNU Coding Standards now declare that the behaviour of binary
: > : >should not depend on its name.
: >
: > The new coding standards
:
: New? Even version 1.1 of GNU standards (Sun Mar 8 06:28:22 1992 UTC (15
: years, 9 months ago)) carries this rule:
:
: http://cvs.savannah.gnu.org/viewvc/gnustandards/standards.texi?revision=1.1&root=gnustandards&view =markup
:
: > put quite a crimp in the use of
: > /sbin/busybox, /sbin/lvm, and a lot of other useful linux modules, I
: > would think.
: >
: > What's the rationale behind this standard?
:
: >From [1]
: <cite>
: @node Preface
: @chapter About the GNU Coding Standards
:
: The GNU Coding Standards were written by Richard Stallman and other GNU
: Project volunteers. Their purpose is to make the GNU system clean,
: consistent, and easy to install. This document can also be read as a
: guide to writing portable, robust and reliable programs. It focuses on
: programs written in C, but many of the rules and principles are useful
: even if you write in another programming language. The rules often
: state reasons for writing in a certain way.
: </cite>
:
: > I've written several
: > useful pieces of signal processing code whose behaviour depends on the
: > name one uses to call it. Now, self-modifying code---that I can
: > understand. :-)
:
: >From [1]
: <cite>
: @cindex program name and its behavior
: @cindex behavior, dependent on program's name
: Please don't make the behavior of a utility depend on the name used
: to invoke it. It is useful sometimes to make a link to a utility
: with a different name, and that should not change what it does.
:
: Instead, use a run time option or a compilation switch or both
: to select among the alternate behaviors.
: </cite>
:
: Ralf
: [1] http://cvs.savannah.gnu.org/viewvc/gnustandards/gnustandards/standards.texi
:

Thanks, Ralf, for enlightening me. I wrote "new coding standards",
above, in response to Stepan Kasal's remark that "GNU Coding Standards
now declare ...". I suppose the latter is literally true even if the
Standard was defined in 1992.

Of course, with this new knowledge, I will feel as free as a bird to
boldly ignore the Standard (in this respect) seeing how several other
prominent linux executables (busybox, lvm, dump/restore, halt, to name
a few) have been blithely ignoring it for more than a decade. :-)

Dean

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-12-2007, 07:50 AM
Joe Smith
 
Default Stupid bash question

Ralf Corsepius wrote:

It would be quite easy to provoke:

Assume a program to change its behavior depending on whether it's called
"X", "Y" or "Z". Now rename it to "A" or try to use copy of X under the
name "myX".

Which behavior will "A" or "myX" expose? The results will be random.


Not necessarily. It would depend on how the program was coded.

Sorry, you're going to have to come up with a more practical example
before I'm convinced.

I do agree with you though that argv[0] is not under the programmer's
control and so it should be treated defensively, just as any other
external input should be. I suppose that could be the intent behind the
word "depend" in the guideline.

If you read it like a lawyer, it only says that the program should not
/depend/ on the name to decide the behavior. Does that mean "not depend
at all" or "not depend solely" on the name?

You could meet the letter of the guideline if the program used its name
as /one way/ to adjust it's behavior, but not the /only/ way.

These positive guidelines:
* The program should have a defined behavior if argv[0] has an
unexpected value,
* All of the program's behaviors should be accessible by options, and
* The options have precedence over argv[0],
are consistent with the negative guideline, without killing the whole
concept.


IMO, the fact you haven't seen such effects only is the result of only
very few programs applying "change behavior upon program name"


I'm no systems whiz, but I've used the technique myself on a number of
occasions and found it handy. I'm going to need something substantial
before I abandon a useful technique. GNU is probably worried about some
larger issues that I don't care so much about.

Here's one possibility: writing a program to run across systems that may
do some ugly name munging with executables, like, oh, calling it
"test.exe" or something. Are there any primitive systems like that still
around?

<Joe



--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-12-2007, 07:56 AM
Ralf Corsepius
 
Default Stupid bash question

On Wed, 2007-12-12 at 00:01 -0800, Dean S. Messing wrote:
> Ralf Corsepius wrote:
> : On Tue, 2007-12-11 at 21:29 -0800, Dean S. Messing wrote:

> : [1] http://cvs.savannah.gnu.org/viewvc/gnustandards/gnustandards/standards.texi
> :
>
> Thanks, Ralf, for enlightening me. I wrote "new coding standards",
> above, in response to Stepan Kasal's remark that "GNU Coding Standards
> now declare ...". I suppose the latter is literally true even if the
> Standard was defined in 1992.
>
> Of course, with this new knowledge, I will feel as free as a bird to
> boldly ignore the Standard (in this respect) seeing how several other
> prominent linux executables (busybox, lvm, dump/restore, halt, to name
> a few) have been blithely ignoring it for more than a decade. :-)
Well, of cause it's everybody's freedom to ignore the "insights" others
have accumulated over many years. But also consider, there are good
reasons why these recommendations exist and why some people consider
programs changing their behavior upon program name to be mal-designed.

Ralf



--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-12-2007, 08:49 AM
Khoa Ton
 
Default Stupid bash question

Ralf Corsepius wrote:

On Wed, 2007-12-12 at 00:01 -0800, Dean S. Messing wrote:

Ralf Corsepius wrote:
: On Tue, 2007-12-11 at 21:29 -0800, Dean S. Messing wrote:



: [1] http://cvs.savannah.gnu.org/viewvc/gnustandards/gnustandards/standards.texi
:


Thanks, Ralf, for enlightening me. I wrote "new coding standards",
above, in response to Stepan Kasal's remark that "GNU Coding Standards
now declare ...". I suppose the latter is literally true even if the
Standard was defined in 1992.

Of course, with this new knowledge, I will feel as free as a bird to
boldly ignore the Standard (in this respect) seeing how several other
prominent linux executables (busybox, lvm, dump/restore, halt, to name
a few) have been blithely ignoring it for more than a decade. :-)

>

Well, of cause it's everybody's freedom to ignore the "insights" others
have accumulated over many years. But also consider, there are good
reasons why these recommendations exist and why some people consider
programs changing their behavior upon program name to be mal-designed.

Ralf


I would appreciate explanations or pointers to the reasons why some
people consider programs changing their behavior upon program name to be
mal-designed.

I find busybox's use of this mechanism interesting, and can't think
of how this can be a more than a slight nuisance to the uninitiated.
For statically linked executables in disk space critical environments,
busybox's use of this mechanism is rather elegant.

Regards,
Khoa





--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-12-2007, 11:38 AM
Ralf Corsepius
 
Default Stupid bash question

On Wed, 2007-12-12 at 01:49 -0800, Khoa Ton wrote:
> Ralf Corsepius wrote:
> > On Wed, 2007-12-12 at 00:01 -0800, Dean S. Messing wrote:
> >> Ralf Corsepius wrote:
> >> : On Tue, 2007-12-11 at 21:29 -0800, Dean S. Messing wrote:
> >
> >> : [1] http://cvs.savannah.gnu.org/viewvc/gnustandards/gnustandards/standards.texi
> >> :
> >>
> >> Thanks, Ralf, for enlightening me. I wrote "new coding standards",
> >> above, in response to Stepan Kasal's remark that "GNU Coding Standards
> >> now declare ...". I suppose the latter is literally true even if the
> >> Standard was defined in 1992.
> >>
> >> Of course, with this new knowledge, I will feel as free as a bird to
> >> boldly ignore the Standard (in this respect) seeing how several other
> >> prominent linux executables (busybox, lvm, dump/restore, halt, to name
> >> a few) have been blithely ignoring it for more than a decade. :-)
> >
> > Well, of cause it's everybody's freedom to ignore the "insights" others
> > have accumulated over many years. But also consider, there are good
> > reasons why these recommendations exist and why some people consider
> > programs changing their behavior upon program name to be mal-designed.
> >
> > Ralf
>
> I would appreciate explanations or pointers to the reasons why some
> people consider programs changing their behavior upon program name to be
> mal-designed.
In short: It's unreliable.

A lengthier answer:


There are several aspects:

1. GNU programs tend to be installed under alternative names, often in
parallel to OS-vendor supplied programs, often into the same directories
or at least into the same PATHs as OS-vendor supplied programs.

Think /usr/bin/make vs. /usr/bin/gmake vs. /usr/bin/gnu-make
vs. /opt/gnu/bin/make vs. E://com/linuxmake.exe vs. ~/check (because
some user copied over /usr/bin/<app> to ~/ because wants to experiment
with it).

Any heuristic to examine argv[] or argv[0] can't avoid to fail somewhere
or at least can't avoid to be somewhat unreliable/unsafe. It's
completely out of an implementors/coders control what a user might be
using as final program name.



2. Technical limitations.
Checking a program's name is not as trivial as it might seem.
- Some OSes mandate program suffixes. A well known example is "*.exe",
but there might be naming conventions on $WEIRDOS, coders/implementors
have never seen before.
- On some OSes, argv[0] is not available (E.g. some embedded OS don't
support it), on some OSes argv[0] carries an absolute path, on some OSes
only a program's basename.


Now consider that these limitations are pretty easy to overcome.
- GNU Standards recommend recommend using an option instead of
name-magic. Most programs already will have option processing, so the
price of adding them should be pretty small.

- An alternative to using options is would be to split the executable
and build several separate apps from them.

> For statically linked executables in disk space critical environments,
> busybox's use of this mechanism is rather elegant.
_statically_ linked in _space critical_ environments. ... That's a
special case, which would touch different questions.

Just take the GNU Standards as "recommendations, generations of smart
people have invested their brains in" - They are not a law. They help
circumventing some issues commonly met on "standard GNU platforms", but
they also have trade-offs and come at a price.

Ralf



--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-12-2007, 12:58 PM
Les Mikesell
 
Default Stupid bash question

Ralf Corsepius wrote:


: [1] http://cvs.savannah.gnu.org/viewvc/gnustandards/gnustandards/standards.texi
:


Thanks, Ralf, for enlightening me. I wrote "new coding standards",
above, in response to Stepan Kasal's remark that "GNU Coding Standards
now declare ...". I suppose the latter is literally true even if the
Standard was defined in 1992.

Of course, with this new knowledge, I will feel as free as a bird to
boldly ignore the Standard (in this respect) seeing how several other
prominent linux executables (busybox, lvm, dump/restore, halt, to name
a few) have been blithely ignoring it for more than a decade. :-)

Well, of cause it's everybody's freedom to ignore the "insights" others
have accumulated over many years. But also consider, there are good
reasons why these recommendations exist and why some people consider
programs changing their behavior upon program name to be mal-designed.


Why is it any more/less significant as a source of error than anything
else on the command line, and is it really worth giving up shared-text
pages when other copies are likely to be executing (like cp/ln/mv)?


And doesn't /bin/sh have some differences with /bin/bash even though
they are the same - and isn't that a GNU-ism?


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 

Thread Tools




All times are GMT. The time now is 07:01 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org