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

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

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

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

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

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

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

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

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

> 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: declare overrides errexit

Le 24/09/2010 15:38, Greg Wooledge a écrit : > If this is turning into a general discussion of errexit (set -e) then > please also see > > http://mywiki.wooledge.org/BashFAQ/105 and > http://fvue.nl/wiki/Bash:_Error_handling These pages are great and should be read. But from experience, I total

Re: declare overrides errexit

Le 24/09/2010 14:52, Sascha Ziemann a écrit : > The expression: > > declare a='x'$(false) > > means: concatenate the string 'x', which evaluates to itself, and the > output of a sub shell, which performs the false command, and assign > the concatenated value to the variable a. > > This means th

Re: Bash style of if-then-else?

> On Thu, Sep 23, 2010 at 04:38:42PM -0500, Michael Witten wrote: >> This is also possible: >> >> [ -f "$file" ] && do_something Note that this style is not compatible with set -e Le 24/09/2010 00:35, Ken Irving a écrit : > While we're talking about style... I prefer using 'test' rather than

Re: RFE: request for grouping mechanism to work in double brackets where otherewise illegal

Le 23/09/2010 02:27, Dennis Williamson wrote: > Not to mention the > tradeoffs that have to be made, in code, in design, in personal time. Speaking of time... the signal/noise ratio in this thread is so unusually low that most subscribers could probably not afford any better than skim over it (my

Re: How to deal with space in command line?

Le 20/09/2010 14:14, Greg Wooledge wrote: > In the original design of the Unix shell, in many ways and places, > it's quite apparent that the designers never really intended to handle > filenames that contain whitespace. ... while at the same time allowing almost any character to be part of a fi

Re: inconsistent field splitting

>> There is a big difference between >> >> $ a=";" >> >> and >> >> $ a=; > And for the VERY ignorant what is the difference In the second case the unescaped semi-colon is a separator totally unrelated to the assignment, which has no value at all. The variable is assigned an empty string.

Re: return from function doesn't work when used in tail of pipeline

A return that's run in a subshell doesn't cause the parent shell to return. **SNIP** >> Are there many people actually using >> "return" to exit a subshell? That would not really make code easy to >> read. > You misunderstood, or I was unclear. *You* misunderstood, or I was

Re: return from function doesn't work when used in tail of pipeline

> On Thu, 12 Aug 2010 08:16:21 -0400, Greg Wooledge >> A return that's run in a subshell doesn't cause the parent shell to >> return. Granted but that does not mean it should behave like "exit", instead it could simply error like this: $ return bash: return: can only `return' from a function or

Re: inconsistent field splitting

Since inconsistency is basically "not the same rule everywhere", it typically shows in (good) documentation. Indeed: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06 2.6 Word Expansions Not all expansions are performed on every word, as explained in the fo

Re: inconsistent field splitting

Le 18/08/2010 12:14, Andreas Schwab a écrit : > Marc Herbert writes: >> In any case it should not perform any *implicit* (and >> thus confusing) quoting. > > There is no quoting, the shell just doesn't split into words, I know but it looks like quoting, because quoti

Re: inconsistent field splitting

> What should a=* or a=$(echo 1 2) do? > Assign only the first file or just 1 to a? or result in an error? Probably result in some error; I do not really care in this initial stage. In any case it should not perform any *implicit* (and thus confusing) quoting. > This hardly seem more consistent

inconsistent field splitting

Compare: for a in "$(echo 1 2)"; do echo "x${a}x"; done x1 2x for a in $(echo 1 2) ; do echo "x${a}x"; done x1x x2x a="$(echo 1 2)"; echo "x${a}x" x1 2x a=$(echo 1 2); echo "x${a}x" x1 2x Shell quoting is difficult enough; why is such an inconsistency making it even more confusi

Re: Issues when func name is the same with an alias

>>This is "much more code": >> >> F(){ find "$@"; } >> > This simple func definition will be 4 lines in my coding style. :) And I > like adding at least one blank line between functions. Then just exclude .bashrc from your coding style.

Re: Issues when func name is the same with an alias

Le 04/08/2010 15:29, Clark J. Wang a écrit : > I do not agree. Aliases are much simpler to use than functions. Please provide examples.

Re: Issues when func name is the same with an alias

Le 04/08/2010 11:39, Clark J. Wang a écrit : > Seems like I must explicitly use the `function' keyword to define foo() for > this scenario. Is that the correct behavior? The correct behaviour is simply not to use aliases, since they bring nothing to the table compared to functions. Have a look at

Re: RFE: allow double quotes to group multi-words & be treated as 1 arg, w/DQ's stripped off -- including RH =~

Le 04/08/2010 09:27, Davide Brini a écrit : > From the Changelog: > > This document details the changes between this version, bash-3.2-alpha, > and the previous version, bash-3.1-release. > ... > 3. New Features in Bash > ... > f. Quoting the string argument to the [[ command's =~ operator now

Re: RFE? request for an "undefined" attribute for functions

Le 02/08/2010 20:11, Bernd Eggink a écrit : > The other is that 'function' is clear and > self-explaining, while 'name()' wrongly suggests that function > parameters should be surrounded by parentheses. ... but only to people whose experience with Unix shells is close to zero. Functions are not

Re: A note for read builtin

>> - The POSIX standard does allow "echo 1 2 | read a b" to be useful >>(cf. 2.12 "Shell Execution Environment"). > Maybe the POSIX expect shell to execute the last command of pipeline > not in subshell. >From section 2.12 and from messages posted here in the past I understand that POSIX

Re: A note for read builtin

Le 16/06/2010 19:03, Greg Wooledge a écrit : > On Wed, Jun 16, 2010 at 07:47:03PM +0200, Krzysztof ??elechowski wrote: >> The description of the read builtin [19] would benefit of the following note: >> Warning: A pipeline of the form { echo 1 2 | read a b; } is not useful. Use >> { >> read<<<"1

Re: Error Handling with bash script

Le 24/05/2010 17:05, Lenga, Yair a écrit: > I would like to propose an improvement to the bash error handling: > Add flag/option "err_return", that will cause a user defined shell > functions to immediately return, when a simple command will return a > non-zero status code. > The behavior is simil

Re: How to autocomplete after 'which'?

Le 21/05/2010 16:25, Peng Yu a écrit : > When I type something after 'which', something means a command. > However, bash doesn't do command completion for the argument after > 'which'. Is there a way to configure bash behave depending on the > context (in this case, do autocomplete after 'which')?

Re: foo* doesn't match when 'foobar' does; fname=FooBar on xfs w/naming "ci" option

Le 21/05/2010 09:32, Linda Walsh a écrit : > I'm not sure if this is bash specific...I'd wager not, but I'm not sure where > to > put it. I guess it is not. > I created an xfs file system with the naming version=ci, (case-ignore) flag. > > This causes it to match filenames with case ignored. >

Re: How to make a directory name with '/' in it?

Le 16/05/2010 16:51, Chris F.A. Johnson a écrit : > >There are two characters that cannot be in a file or directory >name: / and NUL. Interesting essay about this: http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html

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

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

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

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

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

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

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: 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: 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: 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: 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: + 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: 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: 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: 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: 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: 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: $(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: 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: 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: 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?

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

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

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

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?

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

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

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

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

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

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

  1   2   >