Re: Bash bug with ints beyond 2147483646

> echo {2147483640..2147483647} > dies with a malloc error I suggest that Linux kids do not try this at home: the OutOfMemory killer killed a few random processes of mine!

Re: [OT] Linux Out-Of-Memory Killer

Le 03/11/2010 18:50, Bob Proulx a écrit : > Marc Herbert wrote: >> I suggest that Linux kids do not try this at home: the OutOfMemory killer >> killed a few random processes of mine! > > Off-Topic for this mailing list but if so then you should configure > your Linu

Re: Bash bug with ints beyond 2147483646

Le 02/11/2010 19:48, Pete Gregory a écrit : > Easy duplication method: > echo {2147483640..2147483646} > reports > 2147483640 2147483641 2147483642 2147483643 2147483644 2147483645 2147483646 > echo {2147483640..2147483647} > dies with a malloc error - At other times I get this error: *** gli

Re: static vs. dynamic scoping

Eric Blake: > On the Austin Group mailing list, David Korn (of ksh93 fame) > complained[1] that bash's 'local' uses dynamic scoping, but that ksh's > 'typeset' uses static scoping, and argued that static scoping is saner > since it matches the behavior of declarative languages like C and Java > (dy

Re: static vs. dynamic scoping

>> Examples? >> >> http://fvue.nl/wiki/Bash:_Passing_variables_by_reference , I like that. > Very interesting. This reminds me of reflection in Java. Something difficult and dangerous to use, so you never use it directly. Instead you ask a framework or a library ( ~= "upvar" ) to use reflection f

Re: argument precedence, output redirection

Le 03/12/2010 14:46, Payam Poursaied a écrit : > > Hi all, > I'm not sure this is a bug or please let me know the concept: > What is the difference between: > ls -R /etc/ 2>&1 1>/dev/null > and > ls -R /etc/ 1>/dev/null 2>&1 > > the second one redirect everything to /dev/null but the first one,

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

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

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

>> Things like "good default settings" and "batteries included" > > Not sure the reference to python (?) is relevant here,... This was a reference at consumer electronics. Like most living things, pythons do not use any batteries. More seriously Python does not seem to be the only system using

Re: cd with multiple arguments?

Le 13/12/2010 19:48, Stephane CHAZELAS a écrit : > Yes, they're called "commands" or "programs" or "software". > > People tend to forget that before all a shell is a command line > interpreter. > > If you're finding yourself writing complex shell functions that > don't make use of external comman

Re: cd with multiple arguments?

Le 14/12/2010 20:12, Chris F.A. Johnson a écrit : >I stongly disagree with that statement. The shell *is* a programming >language, especially with the extensions in bash. > >In recent years I have stopped using any other language; the shell >is more than adequate for all my progra

Re: cd with multiple arguments?

Le 16/12/2010 01:45, Bob Proulx a écrit : > The shell isn't the only one that introduces a security vulnerability > on most systems when setuid. All interpreters are the same in that > regard. On systems where you shouldn't suid scripts then you > shouldn't suid any of the set of sh/perl/python/r

Re: cd with multiple arguments?

Le 16/12/2010 17:03, Bob Proulx a écrit : > I didn't say anything about quoting. The topic here was security > vulnerabilities of an suid script. For example the classic race > condition between stat'ing the #! interpreter and launching the > privileged process on the file. If the system has tha

Re: cd with multiple arguments?

Le 15/12/2010 18:08, Illia Bobyr a écrit : > On 12/15/2010 4:17 AM, Marc Herbert wrote: >> [...] >> I use and abuse the shell but I do not consider it as a "real" >> programming language is because it was not really designed as one from >> day one. It rather gr

Re: cd with multiple arguments?

Le 17/12/2010 20:57, Bob Proulx a écrit : > CGI scripts are not normally setuid but are running as the web > server process owner You wish... > Instead they stem from a script running unverified user provided > input. [...] It is a problem, and a big one, but completely different from > having a

Re: Making $! and $? searchable in the man page

Le 06/01/2011 09:48, Vidar Holen a écrit : > Finding the meaning of $? and $! in the man page is quite hard for people > not familiar with the layout and bash terminology (this frequently comes > up in Freenode #bash). It would be very helpful for them if you could > simply search for "$!" to find

Re: for; do; done regression ?

Le 10/01/2011 13:38, Greg Wooledge a écrit : > Don't use seq, ever, because it's Linux-only > and is a stupid way to count when bash has builtin integer arithmetic.") seq is not exactly Linux-only but GNU-only. GNU-specific versus bash-specific, which is worse? I'd say it depends... on which mail

Re: for; do; done regression ?

Le 10/01/2011 17:05, Roman Rakus a écrit : > I will say the same on both lists - why to execute another process if > you can do the same in the current one? No gain. Not every "for" loop is in the critical path. Especially not in shell script.

Getting rid of "Terminated" message thanks to SIGINT

Le 30/01/2011 00:12, Chet Ramey a écrit : > Is it a problem? Bash prints messages about signal-terminated processes -- > Most people want to know when their jobs die ...except when they explicitly kill them. > at least those that don't die due to SIGINT or SIGPIPE -- when the > shell is not int

Re: Getting rid of "Terminated" message thanks to SIGINT

>>> Is it a problem? Bash prints messages about signal-terminated processes -- >> >>> Most people want to know when their jobs die >> >> ...except when they explicitly kill them. > > Then maybe the answer is to suppress the message when a process dies > due to SIGTERM, as well as SIGINT. > Sinc

Re: compat31

Le 14/02/2011 15:03, Dennis Williamson a écrit : > I'm having a discussion with someone who claims that for them on Bash > 4.0.33, with compat31 *off*, they are getting 3.1 behavior with quoted > patterns in a =~ match. > > They're saying that this: > > [[ a =~ "." ]] && echo match || echo no >

Re: Do more testing before a release?

Le 17/02/2011 15:46, Eric Blake a écrit : > On 02/16/2011 09:51 PM, Clark J. Wang wrote: >> I know little about open source development process (and control?). I just >> don't know where to get the bash code (like CVS, SVN respository) before >> it's released. I think it's better to make it open to

Re: BASH_SUBSHELL documentation misleading

Le 23/03/2011 20:28, Chet Ramey a écrit : > On 3/23/11 4:15 PM, Sam Liddicott wrote: > >> Yes. But a new subshell environment has been spawned. Each time that >> happens BASH_SUBSHELL should increase. >> >> Of course I know how it does work, but the man page isn't clear. It doesn't >> say that the

Re: BASH_SUBSHELL documentation misleading

Le 24/03/2011 14:50, Greg Wooledge a écrit : > On Thu, Mar 24, 2011 at 02:33:19PM +0000, Marc Herbert wrote: >> I would also like to see this example in the documentation: >> >> $ ( echo sub-$BASH_SUBSHELL ); echo main-$BASH_SUBSHELL >> sub-1 >> main-0 > &

Re: Unexpected behavior with TZ

Le 07/04/2011 23:16, gmail a écrit : > I 'm not fully familiar with POSIX specifications regarding locales, for > now these specifications let me think that this behavior is expected and > that the > LANG environment variable is taken into account after the LC_* > environment variables Would th

3-lines long segfault

The following script crashes bash versions 2.05, 3.2.25, 4.0.16,... trap "echo USR1caught" USR1 read -t 1 foo=$( kill -USR1 $$ ) echo 'Yeah! no Segmentation fault!' Cheers, Marc

Re: 3-lines long segfault

Chet Ramey a écrit : > Marc Herbert wrote: >> The following script crashes bash versions 2.05, 3.2.25, 4.0.16,... >> >> >> trap "echo USR1caught" USR1 >> read -t 1 >> foo=$( kill -USR1 $$ ) >> echo 'Yeah! no Segmentation fault!'

Re: 3-lines long segfault

trap "echo USR1caught" USR1 read -t 1 foo=$( kill -USR1 $$ ) echo 'Yeah! no Segmentation fault!' >>> Thanks for the report. >> Thanks for bash in the first place. >> >> >>> Fixed in the next version. >> Chet, is there any workaround for existing versions? > > Sure. There's th

read -t 0 not supported? (poll)

Hi, It seems polling using "read -t 0" is not supported. Apparently because the implementation is based on alarm() (as opposed to be based on poll()/select()). - is this true? - if yes, doesn't this deserve more explicit documentation? Would anyone know about an alternative, convenient way to

Re: Bash does not read up the whole script which it is currently executing

John Reiser a écrit : > On 08/04/2009 12:48 AM, fam...@icdsoft.com wrote: >> First I would like to say that I'm not sure if this is a bug or a >> feature of Bash. >> If it is a feature, please let me know how to turn it off; or better >> make it disabled by default... >> >> T

Re: Bash does not read up the whole script which it is currently executing

Ivan Zahariev a écrit : > Same here, as Marc said. > > I think that usually we are reading the script from a file and this is > the use-case we must focus on. Currently, we have the problem I > described when executing a script from a file and I think this must be > fixed/changed. Hey, wait.

Re: $var invokes function?

BuraphaLinux Server a écrit : > Not exactly what you asked for, but works the same: > > #! /bin/bash > today() { > date > } > > printf "today is %s\n" "$(today)" > exit 0 > > It is easier to just use $(date) directly though. More direct, but less flexible. printf "arbitrary date is %s\n" "$

Re: Assigning to multiple variables on same line

Yang Zhang a écrit : > Why does assigning to multiple variables on the same line exhibit > sequential consistency normally but not for local variables? You might be interested in another difference: g () { local x x=$(exit 3); echo $? local y=$(exit 3); echo $? } $ g 3 0

Re: bug with 'set -e' + 'trap 0' + syntax error

Stefano Lattarini a écrit : > I thought that when bash detect a syntax errors in a script, > it would pass a $? != 0 to the code in the exit trap, regardless > of whether `set -e' is active or not. > > I think this can be classified as a bug in bash (in some > situations, a very nasty one). Plea

Re: how to keep newlines in ``

Greg Wooledge a écrit : > On Wed, Aug 26, 2009 at 03:04:16PM -0400, Sam Steingold wrote: >> foo=`ls` >> echo $foo > > echo "$foo" What Greg did not explicitly said: 95% of the time you write $foo unquoted, you are wrong and should have written double-quoted "$foo" instead. This not just about n

Re: ulimit and ssh?

peter360 a écrit : > Thanks for the explanation. So my understanding of the way ssh works is > still incorrect. I am confused about at which point the two parameters, > "-c" and "ulimit -a" were converted into three, "-c", "ulimit", and "-a". I > guess I need to read the source of ssh and bas

Re: redirection after braced block

Greg Wooledge a écrit : > On Mon, Oct 05, 2009 at 07:55:33PM +0200, clemens fischer wrote: { ... a number of commands } 2>&1 | ${prog_log} "${logfile}" > > If you're having trouble debugging your script, and you want to be > absolutely sure whether the commands in the bra

Re: preventing pipe reader from existing on writer exiting

Brian J. Murrell a écrit : > > Can anyone help? Ultimately I need to do I/O through a named pipe and I > need to be able to restart the writer without restarting the reader. Have a look at socat. It solved all my FIFO problems.

Re: ignoring comments in a 'cat' call

Bob Proulx a écrit : > > Tamlyn1978 wrote: >> >> Is there a way to make 'cat' ignore the comments or is there a better >> >> alternative to cat in this case? > > > > Note that if 'cat' didn't exactly reproduce the contents of input on > > the output I would consider that a grave bug. Well... GNU

Re: Infinite loop on clearing PWD

jeng...@medozas.de a écrit : > Description: > bash enters into an infinite loop when the environment variable PWD > is unset. Probably not a smart thing to do, but since this variable > is so important, it should probably be ensured that it does not get > an empty value. (It

Re: Infinite loop on clearing PWD

Jan Schampera a écrit : > Marc Herbert schrieb: > >>> Repeat-By: >>> $ unset PWD >> Fix = readonly PWD ? > > This is not a fix, this is a workaround. Sorry Jan: my suggestion was not addressed to you, it was addressed to the maintainer. The idea is to make PWD read-only *by default*.

Re: Infinite loop on clearing PWD

Chet Ramey a écrit : >> Jan Schampera a écrit : >> Sorry Jan: my suggestion was not addressed to you, it was addressed to the >> maintainer. >> >> The idea is to make PWD read-only *by default*. > > Why? There's no identifiable problem here. The original complainant has not > provided any addi

Re: process substitution

> On Mon, Oct 12, 2009 at 1:14 PM, Ralf Goertz >> is it possible to have a process substitution with both input and output >> redirection? So far I use the following work-around >> >>> cat parentprocess.sh: >> #!/bin/bash >> mkfifo fifo 2>/dev/null >> exec 5> >(./subprocess.sh > fifo) >> exec 6< <(

Re: set -e in bash 4

Tobias Poschwatta a écrit : > In the following test case test1.sh, bash 4 behaves differently from > bash 3.1. The behaviour of bash 3.1 is what I would expect to be > correct. Is this a bug in bash 4 or an intentional change? Isn't this related to this change? http://thread.gmane.org/gmane.comp.

Re: cp command will copy to subdirectory without appending /

Bob Proulx a écrit : > Todd Partridge wrote: > If the target has an appended '/' then the destination must be a directory. But with cp (GNU coreutils) 6.12, appending '/' to the target does not seem to make any difference? >> I think the proper behavior here for 'cp -R test2 test' would be to

Re: 100% cpu with: while true ;do read < /dev/null ;done

Jo King a écrit : >> thanks for reply. agree it's not a >> bug with bash. >> >> i am inclinded to agree with the comments but bash is >> popular and attracts a lot of newbies into scripting - a bit >> of smart 'correction' of their wrong ways would at least >> keep the cpu available for other proce

Re: cp command will copy to subdirectory without appending /

> The problem is dead-simple. You cannot run this command multiple times: > > cp -R ./dirfoo ./dirfoo.backup > Sorry to add yet another (last) off topic message but I must do justice to GNU cp. GNU cp actually does support the above thanks to a (non-standard) option: cp -R -T ./dir

Re: slight OT: shell-script programing style -- origins and change?

Stephane CHAZELAS a écrit : > By convention, _environment_ variables are upper-case, which helps > in a shell script to distinguish them with ordinary variables. I > would consider shell scripts with all upper-case variables to be > poorly written, and I agree with the fact that it looks like > yel

Re: [OT] Re: how to start in "overwrite-mode"

Chet Ramey a écrit : > Functions were the last thing added to sh by Steve Bourne before he > left Bell Labs (he finished in 1983) >From Steve Bourne himself: (very interesting interview)

Re: [PATCH] silent job monitor when 'set +m'

Chet Ramey a écrit : >>> Sure. Since the status messages are written to stderr, you can save >>> file descriptor 2 and temporarily (or permanently, depending on your >>> needs) redirect it to /dev/null. >>> >> That means another subshell. > > It doesn't require a subshell to save and restore stde

Re: Error handling question

Greg Wooledge a écrit : > The problem being "how to use set -e in a consistent manner across all > shells"? You can't. set -e is unpredictable, unreliable, and should be > shunned. As you can see by the last dozen or so message on this mailing > list, not even bash gurus (other than Chet) can

Re: Error handling question

Chris F.A. Johnson a écrit : > It isn't desirable. However, commands will sometimes fail; they > are intended to fail. Their failure provides necessary information > to the script. Because it lacks proper exceptions, the language is indeed creating a confusion between exceptional erro

Re: Error handling question

Chet Ramey a écrit : >> The fact that "set -e" is not the default looks like a big design >> mistake to me. > > Wow. That ship sailed 30 years ago. but forgot "set -e" on the quay? See also this ship:

Re: Error handling question

Marc Herbert a écrit : > Chris F.A. Johnson a écrit : >> For example, if you want to know whether user 'john' is in the >> password file: >> >> grep -q ^john: /etc/passwd >> >> You want to get the return code and execute code depending on th

3. Basic Shell Features versus POSIX features

Hi, I more or less assumed that section "3. Basic Shell Features" is all POSIX, in contrast to section "6. Bash Features" which starts like this: "This section 6 describes features unique to Bash." I think I was wrong. There seems to be at least two non-POSIX features documented in the "Basic" s

Re: bash 3.2.39 -- race condition

Douglas Moyes a écrit : > I nearly brought down a server today. > > # alias d="perl-script " > A long time ago I read somewhere that aliases are not recommended. I think they do not bring anything on the table compared to functions, do they? Anyway I have always done without them, but witho

Re: IFS handling and read

Eric Blake a écrit : > > This is E4 in the FAQ: > ftp://ftp.cwru.edu/pub/bash/FAQ > > POSIX permits, but does not require, that the final element of a pipeline > be executed in a subshell. Bash uses the subshell, ksh does not. > Variable assignments in a subshell do not affect the parent. I am

Re: IFS handling and read

Lhunath (Maarten B.) a écrit : > On 30 Nov 2009, at 11:34, Marc Herbert wrote: > >> Eric Blake a écrit : >>> This is E4 in the FAQ: >>> ftp://ftp.cwru.edu/pub/bash/FAQ > Instead of ''commands | read var'' > Use ''rea

Re: IFS handling and read

Chris F.A. Johnson a écrit : >Why should it be the last element of a pipeline that is executed in >the current shell and not the first? Because that's POSIX' choice? Because the last element is the last one in the data stream. So it feels more natural to get everything from the last ele

Re: output redirection with process substitution asynchronous?

> pjodrr wrote: > It would be nice if you explained what it is you're attempting to do, rather > than ask for a solution for what you're thinking would do that. To be honest that is the first thing he (tried to) do: pjodrr wrote: > how can I prefix every line of output of some command with a > t

Re: output redirection with process substitution asynchronous?

Marc Herbert wrote: > What is wrong with the following: > > prefix_with_date () > { > while read; do > printf '%s: %s\n' "$(date)" "$REPLY"; > done > } > > seq 4 | prefix_with_date > ls | prefix_with_date So

Re: output redirection with process substitution asynchronous?

DennisW wrote : > Would you care to comment on the coproc command in Bash 4? I wish I could, but I know nothing about it. Anyone else? pjodrr wrote : > But at least it became clear that the builtin process substitution is > not the solution for me. Wait! Maybe it is. I found a much nicer way to

Re: output redirection with process substitution asynchronous?

pk a écrit : > > I disagree. All the further changes in the requirements because creating a > subshell or being asynchronous is not acceptable etc. are not a goal in > themselves, but rather the indicators that he's trying to accomplish > something else. > I think he just want side-effects li

Re: Command substitution reduce spaces even in strings

ma...@fiz15.jupiter.vein.hu a écrit : > Short example: > $ echo $(echo "'alfa beta'") > 'alfa beta' > > Instead of 'alfa beta' with double space. Always try tracing to understand what is going on: echo $(set -x ;echo "'alfa beta'") ++ echo ''\''alfa beta'\''' http://www.mpi-inf.mpg.de/~u

best way to test for empty dir?

Hi, Does anyone know a more elegant way to check for file existence? Something that does not fork a subshell. And is also more readable maybe. And is obviously not much longer. empty_dir() { test "x$(echo $1/*$2)" = "x$1"'/*'"$2" } Warning: I find neither "noglob" nor "ls" elegant, sorry!

Re: xtrace output on new file descriptor

Brian J. Murrell a écrit : > Is equally difficult? Do you mean "equally difficult" as in "impossible"? Then I would say no, it looks easier :-) > Or can I more easily play with FD duplication and redirection to > achieve that, even if it means adding a ">&word" at the end of things > I want on

Re: best way to test for empty dir?

>>> empty_dir() >>> { >>> test "x$(echo $1/*$2)" = "x$1"'/*'"$2" >>> } pk wrote: > This fails if the directory contains a file called "*". Yes. Unlike the ones below, empty_dir() above considers as empty a directory that has a SINGLE element named '*'. Since I am not so interested in files

Re: best way to test for empty dir?

Sven Mascheck a écrit : > Chris F.A. Johnson wrote: > >> This has been discussed more than once in c.u.s; check the >> archives. > > and that's why we better discuss it here now? I think Chris' message was more like: "let's not discuss it at all and just read the archives" :-] In case anyone

Re: best way to test for empty dir?

Matias A. Fonzo a écrit : > On Fri, 11 Dec 2009 16:16:13 + > Marc Herbert wrote: >> In case anyone is interested my winner (so far) is: >> >> exists() >> { >> [ -e "$1" -o -L "$1" ] >> } >> > > The -L is redunda

Re: add a way to declare global variables

Bernd Eggink a écrit : > To avoid misunderstandings, let me add that you are right (only) with > respect to variables being used _without_ declaration. OK, but not having to explicitly "declare" variables is a feature that most people expect from dynamic languages, so you can hardly blame them fo

Re: $(pwd) != $(/bin/pwd)

Chet Ramey a écrit : > How often does the directory change out from under a > shell process, after which it calls pwd? Depends on what you mean by "change". Very often for testing purposes I re-run some software installer that deletes and re-creates the "tested" directory. So I need to run "cd ."

Re: exec, redirections and variable expansions

mike bakhterev a écrit : > > Description: > Something is wrong with variable substitution in the exec invocation. > When i try to close file descriptor whose number is in variable X with > command: > > exec $X>&- I think the operator is 2> as a whole; you cann

Re: Selecting out of an array

DennisW a écrit : > Also, don't use ls like this - it's eyes-only. Here is a demonstration: touch "filename with spaces" ARRAY=( $(ls) ) # BUG for f in "${arr...@]}"; do echo "file: $f"; done ARRAY=( * ) # OK for f in "${arr...@]}"; do echo "file: $f"; done

Re: Using 'eval'

Gerard a écrit : > This is probably a dumb question; however, I have a question > regarding 'eval'. If you know other programming languages, then it helps to consider "eval" as a technique that generates code at run time (and runs it immediately).

Re: variable assignment in string returning function

Sharuzzaman Ahmat Raslan a écrit : > > Somehow, the backtick for foo() execute the function, echoing the correct > output, but fails to set the variable $gang to the correct value. The variable is set, but in a different sub shell. backticks fork a sub shell. By the way $( ) is preferred to back

Re: Error when script uses CRLF line endings w/ if stmt

Jan Schampera a écrit : > Moreover, POSIX talks about "" here, which is a \n. Though I > didn't read through all the rationales, I just took a quick look, maybe > it's not limited to \n. '\n' can be two characters outside of POSIX, see "man fopen". - It would feel good to use C

Re: + vs. [^/]* - Regular Expression bug?

> * means zero or more characters. It found zero and stopped. I do not think that using a '*' star alone ever makes sense since it is always matches. The star is useful when anchored to something else. Like for instance in: .*Khodabocus '+' is a star anchored to something. Anyway this has n

Re: Is there a special variable for the directory where the script is in?

pk a écrit : > Peng Yu wrote: > >> $0 gives the file name of the script. I could use several shell >> command to get the directory where the script is in. But I'm wondering >> if there is an easy-to-use variable that refers to the directory where >> the script is in? > > See this page: > > http:

Re: process substitution and trailing file descriptors

Ian wrote: > The manual suggests I could move and close file descriptors with > > [n]>&digit- > > but I would need the equivalent of > > command1 >&>(...)- > > Digit might very well mean (just a) digit but here the process > substitution, of course, is replaced with /dev/fd/63, say, certai

Re: Confused about how bash breaks input into words

Eric Blake a écrit : > > Another good reference is POSIX: > http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03 A less rigorous and easier reading is the Guide to Unix Shell Quoting:

Re: Return status of command substitution with $(...) "gets lost"

Chet Ramey a écrit : > On 3/4/10 2:36 AM, Ettelbrueck, Heiko wrote: >> Problem: The $? variable is always 0 after that statement. (If, >> on the other hand, I separate the declaration and the >> definition of the variable as shown in the example below, the >> $? vari

Re: Return status of command substitution with $(...) "gets lost"

Chet Ramey wrote: > To Posix, assignment statements never fail -- assignment errors cause > non- interactive shells to exit, period. In that case, it's possible > to reflect the exit status of a command substitution in the exit > status of a command consisting only of assignment statements,... I

Re: Bash manual - interactive shell definition

>> Could this sentence: >> >> "An interactive shell is one started without non-option arguments, >> unless -sis specified, without specifying the >> -c option, and whose input and error output are both connected to terminals >> (as determined by isatty(3)), or one started with the -i option. " >> >

What is $[ ] ?

Hi, I could not find the dollar square brackets $[ ] expansion documented in the manual. Is it the same as $(( )) ? Cheers, Marc Le 22/03/2010 13:13, tbart...@gmx-topmail.de a écrit : > Configuration Information [Automatically generated, do not change]: > Machine: i686 > OS: linux-gnu > Com

Re: manpage error-Arithmetic Evaluation of numbers with explicit base

Le 29/03/2010 14:50, Thomas Bartosik a écrit : > Please don't get me wrong. I have no problem in understanding the > man page this way, but I do think it is inconsistent. It's a pity that square brackets are used both in the language itself and in its syntactic definitions but this is bound to h

Re: How cd to a directory with special characters like environment\<\-?

Le 08/04/2010 22:58, Peng Yu a écrit : > I make the following directory and try to cd to it. But I can't. Could > you let me know what is the correct way of doing so? > > $ mkdir environment\<\- > $ cd environmen\<\- > -bash: cd: environmen<-: No such file or directory In such situations I find c

Re: Strange behavior of IFS?

Le 15/04/2010 14:58, Clark J. Wang a écrit : > I don't understand why the $string was still splitted into words since > it's double quoted. Anyone can give a reasonable explanation? set -x is often very good at giving explanations. Try this: sh -x foo.sh

Re: Passing variables by reference conflicts with local

Le 01/05/2010 09:18, Freddy Vulto a écrit : > I would like to call t(), and let it return me a filled variable by > reference, that is without polluting the global environment. I'd like to know why you absolutely want the callee to perform a side-effect on the caller. This is your original sin IM

Re: Problem around brackets, && and ||

Le 03/05/2010 21:08, Kunszt Árpád a écrit : >> http://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7C.7C_cmd3 > I read it, thanks. I understand it now. > > I read man bash lots of times, but this behavior had escaped my > attention. There isn't any word about cmd1 && cmd2 || cmd3 only th

Re: Problem around brackets, && and ||

Le 03/05/2010 20:25, Greg Wooledge a écrit : > Use if/then/else/fi instead of && ||. Using && || is dangerous, as I've > explained here: > > http://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7C.7C_cmd3 Also note that using "&&" instead of "if" makes your script totally incompatible with

Re: Passing variables by reference conflicts with local

Le 04/05/2010 14:40, Eric Blake a écrit : > Except that in computing tab completion, side effects are _all_ that > you want - basically, Freddie's problem is how to populate the > global completion variables from within helper functions. Of course you want a side-effect in the caller, and my examp

gmane gateway

Le 16/04/2010 09:09, pk a écrit : > it looks like the gateway between this > group and the mailing list hasn't worked for a long time. Is this intended? > Was it announced somewhere? Are you referring to the gmane group? If yes it has been working perfectly for me over the last few months.

Re: Passing variables by reference conflicts with local

>> Except that it forks a subshell and consumes trailing newlines, and >> the whole point of this exercise is to avoid forks and spurious >> corruption of trailing newlines. > > I will try to find an alternative to eval $( ) The code below allows the callee to return any kind of values (including

Re: How to overwrite a symbolic link?

Le 06/05/2010 15:53, Peng Yu a écrit : > Suppose that I have a symbolic link link1 pointing to file1. When I > write to link1, I don't want file1 change. I want it to remove the > link generated a new file and write to it. This is a very strange question. Symbolic links are expressly designed to f

Re: How to overwrite a symbolic link?

Le 07/05/2010 15:21, Peng Yu a écrit : > Would you please elaborate a little more on how to use LD_PRELOAD to > modify the call. If the library (for example, 'open' from stdlib.h) > is statically compiled in the binary, is LD_PRELOAD going to replace > it with a different 'open' function? Header

Re: How to overwrite a symbolic link?

Le 07/05/2010 16:02, Peng Yu a écrit : > I can copy the whole > directory and then modify one file in the newly copied N files. But > I'll lose track of which file has been changed later on, which is > important to me. You will not lose track of the changed files: just run a recursive diff compari

  1   2   >