Re: Recursively calling a bash script goes undetected and eats all system memory

[Diggory Hardy]

On Thursday 09 December 2010 Pierre Gaston wrote:
> On Wed, Dec 8, 2010 at 11:15 AM, Diggory Hardy  
> wrote:
> > Hello,
> >
> > With a simple script such as that below, bash can enter an infinite loop of 
> > eating memory until the system is rendered unusable:
> >
> > #!/bin/bash
> > PATH=~
> > infinitely-recurse
> >
> > Save this as infinitely-recurse in your home directory and run - and make 
> > sure you kill it pretty quick. OK, so an obvious bug when put like this, 
> > though it bit me recently (mistakenly using PATH as an ordinary variable 
> > and having a script with the same name as a system program). Would it not 
> > be simple to add some kind of protection against this — say don't let a 
> > script call itself more than 100 times?
> >
> > Thanks,
> > Diggory
> >
> Well, I'm not a big fan of the technique, but out there I see a lot of
> wrapper scripts calling themselves to automatically restart an
> application.
> 
Uh. Then over time it is legitimate to have a script recursively call itself a 
few thousand times with each instance still in memory?

The potential to grind the system to a complete halt is pretty serious though. 
Perhaps the ideal solution would be to have the kernel intervene before it 
starts thrashing memory, but that doesn't seem to happen.

Re: Recursively calling a bash script goes undetected and eats all system memory

[Marc Herbert]

> Would it not be simple to add some kind of protection against this

As already mentioned, recursion is a perfectly valid programming
technique so you really cannot forbid it (in fact it is equivalent to
iteration 

Would you also forbid a shell function to call itself?


What you really want is proving termination. Unfortunately this is a
research topic 

Insanely dynamic languages like Unix shell scripting are the most
ill-suited for trying to prove anything.


> say don't let a script call itself more than 100 times?

Yes, in many environment you can configure a maximum recursion level
after which the program gone wild is killed. In your case "ulimit"
might help.

Re: Encoding oddity

[Dennis Williamson]

On Fri, Dec 10, 2010 at 2:04 AM, Richard  wrote:
> Hi!
>
> On 10. des. 2010, at 06.26, Dennis Williamson wrote:
>
>>> --
>>> #!/bin/bash
>>>
>>> touch /Users/myuser/pretérito.txt
>>>
>>> # Example 1
>>> myfile="/Users/myuser/pretérito.txt"
>>>
>>> for b in "$myfile"; do
>>>        if [[ $b == $myfile ]]; then
>>>                echo "OK 1: $b -- $myfile"
>>>        fi
>>> done
>>>
>>> # Example 2
>>> myfolder="/Users/myuser/"
>>> unset b
>>> for b in "$myfolder"*; do
>>>        if [[ $b == $myfile ]]; then
>>>                echo "OK 2: $b -- $myfile"
>>>        fi
>>> done
>>> -
>>>
>>> Richard Taubo
>>>
>>
>>        if [[ $b == $myfolder$myfile ]]; then
>>
>> Try
>>
>> echo $myfolder/*
>>
>> you will see that each file has the directory name prepended.
>
>
> Thanks for feedback!
>
> Do you mean:
>
> --
> #!/bin/bash
>
> touch /Users/myuser/pretérito.txt
> myfile="pretérito.txt"
>
> myfolder="/Users/myuser/"
> for b in "$myfolder"*; do
>      if [[ $b == $myfolder$myfile ]]; then
>               echo $myfolder/*
>       fi
> done
> -
>
> That gives the same result as before, i.e. it does not work.
>
> Thanks!
>
> Richard Taubo

No, I meant to use the echo separately so you could see what the glob was doing.

I'm sorry, because of the way I tested it, I made a mistake in what I
posted. The line should be as you originally had it. It should work.

It sounds like there's a problem with your locale. What does the
locale command output?

Re: Encoding oddity

[Richard]

Hi!

On 10. des. 2010, at 11.56, Dennis Williamson wrote:
--snippet--
> 
> No, I meant to use the echo separately so you could see what the glob was 
> doing.
> 
> I'm sorry, because of the way I tested it, I made a mistake in what I
> posted. The line should be as you originally had it. It should work.
> 
> It sounds like there's a problem with your locale. What does the
> locale command output?
--/snippet--

I have tested the same script under Linux and that works fine.
I changed the Locale for OS X, but the result is the same: It does not work . . 
.

-
Locale OS X original:
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

Locale OS X changed:
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=


Locale Linux:
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
-


Thanks!

Richard Taubo

Re: Recursively calling a bash script goes undetected and eats all system memory

[Greg Wooledge]

On Fri, Dec 10, 2010 at 10:25:02AM +0100, Diggory Hardy wrote:
> Uh. Then over time it is legitimate to have a script recursively call itself
> a few thousand times with each instance still in memory?

No.

> The potential to grind the system to a complete halt is pretty serious
> though. Perhaps the ideal solution would be to have the kernel intervene
> before it starts thrashing memory, but that doesn't seem to happen.

Just use exec.  Re-exec yourself instead of spawning a new instance of
yourself.

Re: Encoding oddity

[Chet Ramey]

On 12/10/10 6:42 AM, Richard wrote:
> Hi!
> 
> On 10. des. 2010, at 11.56, Dennis Williamson wrote:
> --snippet--
>>
>> No, I meant to use the echo separately so you could see what the glob was 
>> doing.
>>
>> I'm sorry, because of the way I tested it, I made a mistake in what I
>> posted. The line should be as you originally had it. It should work.
>>
>> It sounds like there's a problem with your locale. What does the
>> locale command output?
> --/snippet--
> 
> I have tested the same script under Linux and that works fine.
> I changed the Locale for OS X, but the result is the same: It does not work . 
> . .

This is an issue peculiar to Mac OS X.  The Mac file system stores
filenames as decomposed Unicode characters.  Everything else in the
system, including file data and characters entered at the keyboard,
uses precomposed Unicode.  The Finder and some portions of the system
perform the conversion from decomposed to precomposed when mediating
between the file system and the user, but there's no corresponding
conversion performed by what Apple calls "the BSD layer" (basically,
readdir).

I added "file system transformation" functions to bash and filename
rewrite function hooks to readline to deal with this in bash-4.1, but
Apple uses bash-3.2.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Recursively calling a bash script goes undetected and eats all system memory

[Diggory Hardy]

On Friday 10 December 2010 Pierre Gaston wrote:
> On Fri, Dec 10, 2010 at 11:25 AM, Diggory Hardy  
> wrote:
> > On Thursday 09 December 2010 Pierre Gaston wrote:
> >> On Wed, Dec 8, 2010 at 11:15 AM, Diggory Hardy  
> >> wrote:
> >> > Hello,
> >> >
> >> > With a simple script such as that below, bash can enter an infinite loop 
> >> > of eating memory until the system is rendered unusable:
> >> >
> >> > #!/bin/bash
> >> > PATH=~
> >> > infinitely-recurse
> >> >
> >> > Save this as infinitely-recurse in your home directory and run - and 
> >> > make sure you kill it pretty quick. OK, so an obvious bug when put like 
> >> > this, though it bit me recently (mistakenly using PATH as an ordinary 
> >> > variable and having a script with the same name as a system program). 
> >> > Would it not be simple to add some kind of protection against this — say 
> >> > don't let a script call itself more than 100 times?
> >> >
> >> > Thanks,
> >> > Diggory
> >> >
> >> Well, I'm not a big fan of the technique, but out there I see a lot of
> >> wrapper scripts calling themselves to automatically restart an
> >> application.
> >>
> > Uh. Then over time it is legitimate to have a script recursively call 
> > itself a few thousand times with each instance still in memory?
> 
> Well they use exec to avoid that.
> 
> > The potential to grind the system to a complete halt is pretty serious 
> > though. Perhaps the ideal solution would be to have the kernel intervene 
> > before it starts thrashing memory, but that doesn't seem to happen.
> 
> Sure, but you can do that with pretty much any tools available.
> 
True. Sounds like a fix of sorts would be possible though, even if it isn't 
really bash's problem to fix:

What if bash were only to allow scripts to call themselves with exec? If bash 
didn't allow a recursive depth (not via exec) greater than 1000, I presume the 
vast majority of scripts would be unaffected by this, and those that are should 
either use exec instead or are doing something beyond what bash is supposed to 
do.

Or maybe I should just stop poking this problem at you; on the one hand 
software should be forgiving while on the other preventing every possible 
severe error is not easy.

Re: Recursively calling a bash script goes undetected and eats all system memory

[Marc Herbert]

> What if bash were only to allow scripts to call themselves with
> exec?

Tail calls are not the only useful type of recursion, they're just a
particular case  
Sometimes you do want to return (and discard some lower side-effects)

(and it is not always obvious for a script to know what "itself" is)


> on the one hand software should be forgiving while on the other
> preventing every possible severe error is not easy.

Unix was not designed to be forgiving:

Re: Recursively calling a bash script goes undetected and eats all system memory

[Diggory Hardy]

On Friday 10 December 2010 Greg Wooledge wrote:
> On Fri, Dec 10, 2010 at 03:23:46PM +0100, Diggory Hardy wrote:
> > What if bash were only to allow scripts to call themselves with exec?
> 
> You can't prevent programmers from writing horrible code.  At some point,
> it isn't worth the effort even to try.
> 
No you can't.

To be frank sometimes I try to write nice code and sometimes I just try to hack 
something to do what I want. The more bugs an interpreter or compiler can catch 
the better though, particularly with regards to those who are not experts in a 
language.

bash 'let' can give error

[Dominic Raferd]

Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' 
-DCONF_OSTYPE='linu
x-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' 
-DLOCALEDIR='/usr/
share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I../bash 
-I../bas

h/include -I../bash/lib   -g -O2 -Wall
uname output: Linux rdiff-backup1 2.6.32-26-generic-pae #48-Ubuntu SMP 
Wed Nov 2

4 10:31:20 UTC 2010 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu

Bash Version: 4.1
Patch Level: 5
Release Status: release

Description:

$ val=0; let val++; echo $val,$?; unset val
1,1

see the error code 1. Setting any other start value (except undefined) 
for val does not produce this error, the problem occurs for let val++ 
and let val-- if the start value is 0.


for let ++val and let --val the problem occurs if the result is 0. Also 
for the

command:

$ val=10; let val=val+2*2-14; echo $val,$?; unset val


Repeat-By:
See the examples above

Why does this happen? Is it 'by design'? It makes arithmetic with bash 
let very dangerous because it can throw unexpected errors (and break 
scripts running with  set -e).

Re: "gitk &" closes parent bash upon exit

[Illia Bobyr]

On 9/26/2010 6:24 PM, Keith Thompson wrote:
> Keith Thompson  writes:
>> "Illia Bobyr"  writes:
>> [...]
>>>   When I do "gitk&" upon gitk exit the parent bash process
>>> terminates as well.
>>>   When I do "(gitk&)" it works fine.  There does not seem to be any
>>> crash dumps.  But sometimes bash outputs "Logout" before it exits just
>>> as if I would press ^D on prompt.  I have tried putting "gitk&" call
>>> into a script and adding traps for all possible signals but none seemed
>>> to be fired.
>>>   You do not have to be in a directory that is a Git repository.
>> I wonder how "set -o ignoreeof" in the parent shell would affect
>> the behavior.
> I don't see this behavior, either with or without "set -o ignoreeof".
>
> I see a pop-up error message: "Cannot find a git repository here";
> when I click "OK" the message vanishes, gitk terminates, and the
> parent bash shell is undisturbed.  Same thing whether bash is
> running under rxvt, xterm, or a Windows command window.
>
> $ cygcheck -c -d cygwin gitk bash
> Cygwin Package Information
> Package  Version
> bash 3.2.49-23
> cygwin   1.7.5-1
> gitk 1.7.0.4-2

It is a known issue with Cygwin 1.7.7:

http://www.mail-archive.com/bug-bash@gnu.org/msg07983.html
http://cygwin.com/ml/cygwin/2010-09/msg00641.html

Ilya

Re: bash 'let' can give error

[Eric Blake]

On 12/09/2010 10:52 AM, Dominic Raferd wrote:
> Description:
> 
> $ val=0; let val++; echo $val,$?; unset val
> 1,1

Not a bug.

> 
> see the error code 1. Setting any other start value (except undefined)
> for val does not produce this error, the problem occurs for let val++
> and let val-- if the start value is 0.

let intentionally returns status 1 if the value was 0; and status > 1 if
there was an error.  Why?  So you can do loops such as:

countdown=10
while let countdown--; do ... ; done

> Why does this happen? Is it 'by design'?

Yes.  The same as for 'expr' which is standardized by POSIX to have the
same behavior.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bash 'let' can give error

[Greg Wooledge]

On Thu, Dec 09, 2010 at 05:52:49PM +, Dominic Raferd wrote:
> Why does this happen? Is it 'by design'? It makes arithmetic with bash 
> let very dangerous because it can throw unexpected errors (and break 
> scripts running with  set -e).

http://mywiki.wooledge.org/BashFAQ/105 -- Why doesn't set -e (set -o
errexit) do what I expected?

Re: bash 'let' can give error

[Andreas Schwab]

Dominic Raferd  writes:

> Why does this happen? Is it 'by design'?

$ help let
[...]
Exit Status:
If the last ARG evaluates to 0, let returns 1; let returns 0 otherwise..

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bash 'let' can give error

[Marc Herbert]

> let intentionally returns status 1 if the value was 0; and status > 1 if
> there was an error.  Why?  So you can do loops such as:
> 
> countdown=10
> while let countdown--; do ... ; done
> 
>> Why does this happen? Is it 'by design'?
> 
> Yes.  The same as for 'expr' which is standardized by POSIX to have the
> same behavior.

This is a design mistake: it trades a few characters for a lot of confusion.

Re: bash 'let' can give error

[Eric Blake]

On 12/10/2010 08:49 AM, Marc Herbert wrote:
>> let intentionally returns status 1 if the value was 0; and status > 1 if
>> there was an error.  Why?  So you can do loops such as:
>>
>> countdown=10
>> while let countdown--; do ... ; done
>>
>>> Why does this happen? Is it 'by design'?
>>
>> Yes.  The same as for 'expr' which is standardized by POSIX to have the
>> same behavior.
> 
> This is a design mistake: it trades a few characters for a lot of confusion.

It's required for 'expr'.  But since 'let' is a bash extension, bash is
free to change the semantics of 'let' to behave differently.  However,
doing so now would break backwards compatibility with existing scripts
that have come to depend on this behavior, so unfortunately we're stuck
with it.

Remember, non-zero status is NOT always 'failure'; it is the
documentation of each command that will tell you which status values
imply failure.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bash 'let' can give error

[Andreas Schwab]

Marc Herbert  writes:

>> let intentionally returns status 1 if the value was 0; and status > 1 if
>> there was an error.  Why?  So you can do loops such as:
>> 
>> countdown=10
>> while let countdown--; do ... ; done
>> 
>>> Why does this happen? Is it 'by design'?
>> 
>> Yes.  The same as for 'expr' which is standardized by POSIX to have the
>> same behavior.
>
> This is a design mistake: it trades a few characters for a lot of confusion.

You can always choose to ignore the exit status.  The converse is not
true.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bash crashes with named pipes

[Chet Ramey]

On 6/11/10 5:10 PM, Kevin wrote:
> Maybe I'm doing something wrong, but the following will make bash
> crash.
> 
> 
> terminal 2:
> $ mkfifo test
> $ while true; do echo foo && sleep 1; done > test
> 
> terminal 1:
> $  
> wait for a few "foo"s to be printed and then kill with ctrl-c
> terminal 2 will read:
> 
> Warning: Program '/bin/bash' crashed.

Bash gets a SIGPIPE and exits, since that's a fatal signal.  The question
is whether it should try and figure out whether the file it's writing to
is a pipe and catch and discard SIGPIPE if so.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: bash 'let' can give error

[Dominic Raferd]

On 10/12/2010 15:15, Greg Wooledge wrote:

On Thu, Dec 09, 2010 at 05:52:49PM +, Dominic Raferd wrote:

Why does this happen? Is it 'by design'? It makes arithmetic with bash
let very dangerous because it can throw unexpected errors (and break
scripts running with  set -e).

http://mywiki.wooledge.org/BashFAQ/105 -- Why doesn't set -e (set -o
errexit) do what I expected?
Thanks Greg (and also Eric and Andreas). Your FAQ makes it very clear; 
that is to say, it makes it clear how darned complicated it is. Seems 
best to avoid using 'set -e' altogether, as you say (except perhaps at 
an early stage for debugging): point taken.


Dominic

Re: Recursively calling a bash script goes undetected and eats all system memory

[Pierre Gaston]

On Fri, Dec 10, 2010 at 11:25 AM, Diggory Hardy  wrote:
> On Thursday 09 December 2010 Pierre Gaston wrote:
>> On Wed, Dec 8, 2010 at 11:15 AM, Diggory Hardy  
>> wrote:
>> > Hello,
>> >
>> > With a simple script such as that below, bash can enter an infinite loop 
>> > of eating memory until the system is rendered unusable:
>> >
>> > #!/bin/bash
>> > PATH=~
>> > infinitely-recurse
>> >
>> > Save this as infinitely-recurse in your home directory and run - and make 
>> > sure you kill it pretty quick. OK, so an obvious bug when put like this, 
>> > though it bit me recently (mistakenly using PATH as an ordinary variable 
>> > and having a script with the same name as a system program). Would it not 
>> > be simple to add some kind of protection against this — say don't let a 
>> > script call itself more than 100 times?
>> >
>> > Thanks,
>> > Diggory
>> >
>> Well, I'm not a big fan of the technique, but out there I see a lot of
>> wrapper scripts calling themselves to automatically restart an
>> application.
>>
> Uh. Then over time it is legitimate to have a script recursively call itself 
> a few thousand times with each instance still in memory?

Well they use exec to avoid that.

> The potential to grind the system to a complete halt is pretty serious 
> though. Perhaps the ideal solution would be to have the kernel intervene 
> before it starts thrashing memory, but that doesn't seem to happen.

Sure, but you can do that with pretty much any tools available.

Re: cd with multiple arguments?

[Marc Herbert]

> It's trivial to write a shell function to do that, and many other things.

Things like "good default settings" and "batteries included" typically
make users switch from one tool to another.

This just FYI; I realize some goals might not compatible with utter
user-friendliness, and that there is often room for different
approaches.

Re: Recursively calling a bash script goes undetected and eats all system memory

[Greg Wooledge]

On Fri, Dec 10, 2010 at 03:23:46PM +0100, Diggory Hardy wrote:
> What if bash were only to allow scripts to call themselves with exec?

You can't prevent programmers from writing horrible code.  At some point,
it isn't worth the effort even to try.

Re: bash 'let' can give error

[Marc Herbert]

Le 10/12/2010 16:05, Andreas Schwab a écrit :
>>
>> This is a design mistake: it trades a few characters for a lot of confusion.
> 
> You can always choose to ignore the exit status.  The converse is not
> true.

Agreed, but that does not imply any command should try to be creative
and throw random status values in obscure corner cases just to show off.

Re: bash 'let' can give error

[Ken Irving]

On Thu, Dec 09, 2010 at 05:52:49PM +, Dominic Raferd wrote:
> $ val=0; let val++; echo $val,$?; unset val
> 1,1
> 
> see the error code 1. Setting any other start value (except
> undefined) for val does not produce this error, the problem occurs
> for let val++ and let val-- if the start value is 0.
> 
> for let ++val and let --val the problem occurs if the result is 0.
> Also for the
> command:
> 
> $ val=10; let val=val+2*2-14; echo $val,$?; unset val
> 
> ...
> Why does this happen? Is it 'by design'? It makes arithmetic with
> bash let very dangerous because it can throw unexpected errors (and
> break scripts running with  set -e).

I don't know why this is done, but the behavior is clearly documented
in the manpage:

   let arg [arg ...]
  Each arg is an arithmetic expression to be evaluated (see ARITH-
  METIC EVALUATION above).  If the last arg evaluates  to  0,  let
  returns 1; 0 is returned otherwise.

Ken

errexit/set -e again (was: bash 'let' can give error)

[Marc Herbert]

Le 10/12/2010 16:19, Dominic Raferd a écrit :
> Thanks Greg (and also Eric and Andreas). Your FAQ makes it very clear; 
> that is to say, it makes it clear how darned complicated it is. Seems 
> best to avoid using 'set -e' altogether, as you say (except perhaps at 
> an early stage for debugging): point taken.

I use set -e almost systematically in non-trivial code and I am very
happy with it. Except in extremely rare cases, when I accidentally
forget to append "|| true" after... let. This is still far less annoying than
having scripts that keep running after a failure. Or having to append "|| die"
after each command.


If you are really too afraid to use it in production it can still
prove useful like this:

if $DEBUG_MODE; then
  set -e
fi


Following a number of discussions on this list, I feel like the majority of
highly respected experts here who regularly warn against set -e have
never seriously tried to use it on a large scale.


Le 10/12/2010 15:54, Eric Blake a écrit :
> Remember, non-zero status is NOT always 'failure'; it is the
> documentation of each command that will tell you which status values
> imply failure.

I do not find this to be a problem in practice: except for "let" the
exit status is very intuitive for practically every command.

Re: bash 'let' can give error

[Chet Ramey]

On 12/10/10 12:17 PM, Marc Herbert wrote:
> Le 10/12/2010 16:05, Andreas Schwab a écrit :
>>>
>>> This is a design mistake: it trades a few characters for a lot of confusion.
>>
>> You can always choose to ignore the exit status.  The converse is not
>> true.
> 
> Agreed, but that does not imply any command should try to be creative
> and throw random status values in obscure corner cases just to show off.

That's a little harsh, don't you think?  The behavior of let and its
sibling `((', and expr before it, is designed to make this kind of thing
very easy:

while (( x )); do something with x and decrement it ; done

The exit status rules are very simple and well-defined.  If you don't
like the way let works, there's nothing stopping you from using `:'
or straight variable assignment together with $((...)).

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: cd with multiple arguments?

[Chris Jones]

On Fri, Dec 10, 2010 at 05:24:34AM EST, Marc Herbert wrote:

> > It's trivial to write a shell function to do that, and many other
> > things.
> 
> Things like "good default settings" and "batteries included" 

Not sure the reference to python (?) is relevant here, since the
language by itself does not do much and the included ‘batteries’ are
almost entirely provided via modules, all in all an approch not very
different from Chet's suggesting writing a function. 

True, bash does not come with a vast library of ready-to-use functions.

> ... typically make users switch from one tool to another.

And what some see as features, others call.. bloat. 

Personally, what made me abandon bash early on and switch to python for
most of my scripting needs was that by the time I reached the end of the
manual, I had already forgotten the beginning. :-)

cj