Re: cd with multiple arguments?

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

Re: bash 'let' can give error

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 an

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

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):

Re: bash 'let' can give error

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

Re: bash 'let' can give error

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

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

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: cd with multiple arguments?

> 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 o

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

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 s

Re: bash 'let' can give error

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.wool

Re: bash crashes with named pipes

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 w

Re: bash 'let' can give error

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 'ex

Re: bash 'let' can give error

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. T

Re: bash 'let' can give error

> 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 POS

Re: bash 'let' can give error

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 827

Re: bash 'let' can give error

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 s

Re: bash 'let' can give error

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

Re: "gitk &" closes parent bash upon exit

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 somet

bash 'let' can give error

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=

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

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

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

> 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 obv

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

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,

Re: Encoding oddity

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 lin

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

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 t

Re: Encoding oddity

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

Re: Encoding oddity

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 "$

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

> 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

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

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=~ > > i