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, 02:20 PM
Karl Larsen
 
Default Stupid bash question

Les Mikesell wrote:

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?


I ran into yesterday a bash blog. It appears to be of the form
<dsp>=/dev/dsp and I was not aware this is a blog. But then I am not a
bash user much.




--

Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
GPG DF28 8F18 94F8 D5C6 9E44 163F 7FD1 3D06 C325 DA40

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

Ralf Corsepius wrote:

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


I appreciate your concise and thorough explanations, Ralf.

Khoa

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

At 12:01 AM -0800 12/12/07, Dean S. Messing wrote:
...
>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. 1?2:-)

Also sendmail, which is also known as newaliases, mailq, hoststat, and
purgestat -- but none of these programs come directly from GNU, as test
does. Splitting test and [ seems to me a mistake of too much purity. I
think the guidelines should list a few examples (the linker seems a good
one) and a few counter-examples (sendmail due to long useage, test due to
the need for [ to be exactly the same as test except for requiring a last
option of ].
--
__________________________________________________ __________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 08-15-2012, 10:19 PM
Craig White
 
Default stupid bash question

the relevant snippet is...

NAME="*.mov"
cd $IN
if test -n "$(find . -maxdepth 1 -name $NAME -print -quit)"

and if there is one file in this directory - ie test.mov, this works fine

but if there are two (or more) files in this directory - test.mov, test2.mov

then I get an error...
find: paths must precede expression

So my code is evidently wrong. I just want a test for 1 or more files ending in .mov in the directory?

Any one want to toss me a bone here?

--
Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white@ttiltd.com
1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com

Need help communicating between generations at work to achieve your desired success? Let us help!

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-15-2012, 10:22 PM
Larry Martell
 
Default stupid bash question

On Wed, Aug 15, 2012 at 4:19 PM, Craig White <craig.white@ttiltd.com> wrote:
> the relevant snippet is...
>
> NAME="*.mov"
> cd $IN
> if test -n "$(find . -maxdepth 1 -name $NAME -print -quit)"
>
> and if there is one file in this directory - ie test.mov, this works fine
>
> but if there are two (or more) files in this directory - test.mov, test2.mov
>
> then I get an error...
> find: paths must precede expression
>
> So my code is evidently wrong. I just want a test for 1 or more files ending in .mov in the directory?
>
> Any one want to toss me a bone here?

Run the script with -x to see what's happening. $NAME is probably
getting expanded. You might have to set noglob.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-15-2012, 10:45 PM
Steve Thompson
 
Default stupid bash question

On Wed, 15 Aug 2012, Craig White wrote:

> the relevant snippet is...
>
> NAME="*.mov"
> cd $IN
> if test -n "$(find . -maxdepth 1 -name $NAME -print -quit)"
>
> and if there is one file in this directory - ie test.mov, this works fine
>
> but if there are two (or more) files in this directory - test.mov, test2.mov
>
> then I get an error...
> find: paths must precede expression

The substitution of $NAME is expanding the wild card, giving you a single
-name with two arguments. You probably want something like:

NAME="*.mov"

Steve
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-15-2012, 10:51 PM
Jrmie Dubois-Lacoste
 
Default stupid bash question

I gess you could also avoid the expension with:
if test -n "$(find . -maxdepth 1 -name "$NAME" -print -quit)"

2012/8/15 Steve Thompson <smt@vgersoft.com>:
> On Wed, 15 Aug 2012, Craig White wrote:
>
>> the relevant snippet is...
>>
>> NAME="*.mov"
>> cd $IN
>> if test -n "$(find . -maxdepth 1 -name $NAME -print -quit)"
>>
>> and if there is one file in this directory - ie test.mov, this works fine
>>
>> but if there are two (or more) files in this directory - test.mov, test2.mov
>>
>> then I get an error...
>> find: paths must precede expression
>
> The substitution of $NAME is expanding the wild card, giving you a single
> -name with two arguments. You probably want something like:
>
> NAME="*.mov"
>
> Steve
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-15-2012, 11:01 PM
Patrick Welch
 
Default stupid bash question

Put escaped double quotes around name, like "$NAME" in the test expression.
--
Pat Welch
Sent from my Android phone with K-9 Mail.

Craig White <craig.white@ttiltd.com> wrote:

the relevant snippet is...

NAME="*.mov"
cd $IN
if test -n "$(find . -maxdepth 1 -name $NAME -print -quit)"

and if there is one file in this directory - ie test.mov, this works fine

but if there are two (or more) files in this directory - test.mov, test2.mov

then I get an error...
find: paths must precede expression

So my code is evidently wrong. I just want a test for 1 or more files ending in .mov in the directory?

Any one want to toss me a bone here?

--
Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white@ttiltd.com
1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com

Need help communicating between generations at work to achieve your desired success? Let us help!

_____________________________________________

CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-15-2012, 11:08 PM
Craig White
 
Default stupid bash question

Some really good suggestions but unfortunately no dice

On Aug 15, 2012, at 3:22 PM, Larry Martell wrote:

> Run the script with -x to see what's happening. $NAME is probably
> getting expanded. You might have to set noglob.
----
set +o noglob (inside or outside script made no difference
----
On Aug 15, 2012, at 3:45 PM, Steve Thompson wrote:

> The substitution of $NAME is expanding the wild card, giving you a single
> -name with two arguments. You probably want something like:
>
> NAME="*.mov"

-----
Definitely agree that it's expanding the glob but this doesn't work
-----
On Aug 15, 2012, at 3:51 PM, Jrmie Dubois-Lacoste wrote: (and Patrick Welch too)

> I gess you could also avoid the expension with:
> if test -n "$(find . -maxdepth 1 -name "$NAME" -print -quit)"
----
thought this would be a winner but it seems to completely miss everything with the $NAME completely

Thanks

Craig
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-15-2012, 11:19 PM
Larry Martell
 
Default stupid bash question

On Wed, Aug 15, 2012 at 5:08 PM, Craig White <craig.white@ttiltd.com> wrote:
> Some really good suggestions but unfortunately no dice
>
> On Aug 15, 2012, at 3:22 PM, Larry Martell wrote:
>
>> Run the script with -x to see what's happening. $NAME is probably
>> getting expanded. You might have to set noglob.
> ----
> set +o noglob (inside or outside script made no difference

This worked for me:

$ cat t.sh
set -o noglob
NAME="*.mov"
find . -maxdepth 1 -name $NAME -print

$ touch t.mov t2.mov
$ bash t.sh
./t.mov
./t2.mov
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 06:12 AM.

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