Re: Undocumented behaviour - parameter expansion ${par-word}
On 04.09.2012 13:13, Roman Rakus wrote:
Hi,
Petr, adding to cc: list, found behaviour not documented, neither in man
page nor bash ref manual:
${par-word} will do expansion of par, and if the par is unset it is
substituted by word. It is different from ${par:-word}, where word is
used when par is unset or null.
Is it undocumented and deprecated, like $[]? Or just undocumented?
Hi Roman,
it actually is documented (and it's more general, not limited to "-")
[...]
When not performing substring expansion, using the forms documented
below, bash tests for a parameter that is unset or null. Omitting the
colon results in a test only for a parameter that is unset.
[...]
--
Be conservative in what you do, be liberal in what you accept from others.
- jbp, master of the net, in RFC793
Re: Massive recursion -> SEGV
On 02.07.2012 20:57, Chet Ramey wrote: On 7/2/12 2:36 PM, Jan Schampera wrote: The origin of this all was a "bugreport" to me about the manual lying about no limits on recursion That's funny. Aye. A bit of confusion. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Massive recursion -> SEGV
On 02.07.2012 15:57, Eric Blake wrote: Look for FUNCNEST variable. In recent release it is available. I more meant the shell interpreter, less the code I can write. It would be possible to link bash with libsigsegv to install a graceful stack overflow handler that allows a nicer exit message on failure; other GNU projects that have done so include awk and m4. But short of introducing arbitrary limits (which goes against GNU philosophy), it is not possible to detect stack overflow until after it happens, and the only recovery possible after detecting stack overflow is a graceful message and exit unless you go to extreme lengths to block signals around every call to malloc or any other library function that grabs a lock. Hi Eric, yes, it's more about helpful messages (not neccesarily a recovery), less about limits in Bash or application (script, etc.). The origin of this all was a "bugreport" to me about the manual lying about no limits on recursion - it turned out it was massive recursion and little stack - and a resulting SEGV. I'm interested in people's thoughts there, like is it okay to just crash or would a message be better? libsigsegv - I'll have a look. Thanks. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Massive recursion -> SEGV
On 01.07.2012 14:37, Roman Rakus wrote: Look for FUNCNEST variable. In recent release it is available. I more meant the shell interpreter, less the code I can write. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Massive recursion -> SEGV
Hi folks,
a suggestion about recursive function calls (and not only that, of course).
Do you see a way for Bash to pull the emergency break before it runs out
of stack here (to provide an error to the user, rather than a crash):
f1() {
f1
}
f1
Currently it runs into a SEGV, where the number of recurions depends on
the stack limit.
On a fast search I found no portable way, but there are ways for
specific platforms, like getrusage() when stack is reported there.
--
Be conservative in what you do, be liberal in what you accept from others.
- jbp, master of the net, in RFC793
Re: sorry--this is my question
On 22.07.2011 18:12, the mad doctor kaeding wrote: is this a bug? echo goodbye\ cruel\ world\! goodbye cruel world! echo "goodbye cruel world!" bash: !": event not found echo "goodbye cruel world\!" goodbye cruel world\! No, this is a specific history expansion in interactive shells. Execute ''set +H'' and try again (it's disabled in non-interactive shells). -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: printf treats arguments of "%c" not as expected
Yunfeng Wang wrote: Perhaps bash should clarify this issue in its documents such that users like me would not be misguided again. Since the reference to printf(3) is misleading sometimes, I made some document [1] for Bash's printf only. It's far from perfect, but at least it mentions %s and "first character" ;-) Jan [1] http://wiki.bash-hackers.org/commands/builtin/printf -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: printf treats arguments of "%c" not as expected
Hi, I agree this is not a bug. %c works as described. However, Mr. Wang may want to read one of Greg's brilliant FAQ entries [1]. In general it's a bit of a pity that printf can do character->number conversion, but not (directly) back. But it is like it is and the "workarounds" are not really complicated. Jan [1] http://mywiki.wooledge.org/BashFAQ/071 -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Permission denied to execute script that is world executable
John Williams wrote: I find that I cannot execute world-executable scripts when they are in a directory which is mounted on a drive on an HBA (host bus adapter Can you show the mount options of the filesystem? -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Question about testing with variable operators
Andreas Schwab wrote: "Steven W. Orr" writes: As a work around, I can use eval or the builtin test, but my question is this: Is this a bug or is there a reason that it should work for arithmetic but not for the test [[ operator? [[ is a reserved word like if, which triggers special parsing rules, so you cannot use it like this. However, it should work for the good ol' test command ([ ... ]) -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: documentation bug re character range expressions
Hi, just as side note, not meant to touch the maintainer discussion. This is not only a "Bash problem". The programmer/user mistake to use [A-Z] for "only capital letters, capital A to capital Z" is a very common one. But I'm not sure if every official application-level documentation should cover those kind of pitfalls. There would be many topics around "bad programming habbits" that should be documented. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Bash source repository
Bradley M. Kuhn wrote: I humbly suggest that http://git.savannah.gnu.org/cgit/bash.git be replaced with this repository above that I've created. The new repository contains everything that the current Savannah one does, but I put much more effort into making commits fine-grained, rather than merely importing the public releases blindly. (For example, I did 'git mv' where it was obvious a move occurred, so that changes in file movements were properly tracked historically). A good work. I agree with using this as a base to reflect future development. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Here strings and pathname expansion
Roman Rakus wrote: It is noted in Here Documents (and Here Strings is a variant of here documents). And there is: No parameter expansion, command substitution, arithmetic expansion, or pathname expansion is performed on word. This is not true for here strings (infact, it wouldn't make sense for here strings to disallow for example parameter expansion). I see the relation to here documents. I just tried to point out that either thze documentation or the behaviour should be revised. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Here strings and pathname expansion
Hello world,
I recently answered a question about using the asterisk mixed with
redirection and other words. This also lead me to the documentation that
states (REDIRECTION section):
---
The word following the redirection operator in the following
descriptions, unless otherwise noted, is subjected to brace expansion,
tilde expansion, parameter expansion, command substitution, arithmetic
expansion, quote removal, pathname expansion, and word splitting. If it
expands to more than one word, bash reports an error.
---
This is true, for here documents the exceptions are mentioned. However,
for here strings no exceptions are mentioned ("The WORD is expanded
[...]]", but the WORD is at least not subject to pathname expansion:
$ cat <<< *
*
This is EITHER
(a) a documentation mistake OR
(b) a bug
Case (a) is clear, the exception is not mentioned.
Case (b) is also possible, because it COULD be intended to
pathname-expand WORD:
(1) error out if pathname expansion results in more than one word OR
(2) use the first word of the result OR
(3) pass all results (as a special case)
I would expect the thing to either be (a) or (b)(2).
--
Be conservative in what you do, be liberal in what you accept from others.
- jbp, master of the net, in RFC793
Re: for; do; done regression ?
Marc Herbert wrote: seq is not exactly Linux-only but GNU-only. GNU-specific versus bash-specific, which is worse? I'd say it depends... on which mailing-list you post :-) I'd say a script interpreted by the GNU shell must not rely blindly on GNU tools being installed or on running on a GNU OS. It can, however, rely on Bash features, of course. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: 'help set' missing '--'
Dennis Williamson wrote: I think this distinction from the man page is what's missing in the help: > [...] Exactly. Thanks for pointing it out, I thought it was clear :) -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: 'help set' missing '--'
Greg Wooledge wrote: Or: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...] More: set [-abefhkmnptuvxBCHP] [-o option-name] [-] [--] [arg ...] Plus: Describe '--' the same way '-' is described (with an extra part in the full help message below the synopsis). -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
'help set' missing '--'
Hello, the help output for the set builtin command misses '--'. The manpage is ok. (recognized by 'yitz' on irc://irc.freenode.net/#bash) -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Huge execution time in 4.2, WAS: for; do; done regression ?
Chet Ramey wrote: I can't imagine this is just some debugging code still active (it's a beta). Imagine. Anything that doesn't have a version tag of `release' has DEBUG enabled for the preprocessor, which enables MALLOC_DEBUG. If you're using the bash malloc, MALLOC_DEBUG turns on extensive memory checking and allocation tracing. All active allocations are kept in a hash table with 8K entries, and when you fill up that hash table, each new allocation has to search the entire table before throwing away an old entry. That quickly degenerates. This can be fixed, but it hasn't become a priority yet. Wow. A huge difference. Anyways, if you tell me how I'll try to track it down, but I read in the other thread you already try to gprof it. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Huge execution time in 4.2, WAS: for; do; done regression ?
Alexander Tiurin wrote: ~$ time for i in `seq 0 1` ; do echo /o/23/4 | cut -d'/' -f2 ; done > /dev/null To track this a bit, I ran the exact command several times in a Bash 3.2, seeing increasing execution times (40s up to ~2min), as reported. I knew there were several bugs about filedescriptors and leaks fixed since then, so I tested it in 4.2 beta. The first run took about 27 minutes(!), the second run still goes on. I can't imagine this is just some debugging code still active (it's a beta). Anybody else able to reproduce this? -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
read builtin and readonly variables
Hello list, the read builtin command, when trying to assign to a readonly variable after reading the data, spits an error message. This is fine. But the return status is 0. It "always" (down to 2.04 was tested) has been like that, and it's like that in upcoming 4.2. For me, this doesn't make sense. The read may have been successful, but the data is gone. It would make sense to return !=0 here, IMHO. I also quickly cross-read POSIX, since such weirdness usually comes from there ;-) but I didn't see anything obvious. Regards, Jan -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Word splitting and arithmetic expansion
Chet Ramey wrote: Arithmetic expansion is a Posix invention. It's treated just like every other expansion: split unless double quoted. There's no compelling reason to make it behave differently. I don't want it to behave differently :) Okay, so it's just "as is", because by consistent design all expansions are subject to WS (with some exceptions). Pathname expansion happens after word splitting. Tilde expansion is the one that's not subject to word splitting. This is clear, it was an unlucky example (pathname expansion's location in the processing is where it is to prevent WS, but tilde expansion is a better example since it happens before WS and is excluded from WS). Thanks. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Word splitting and arithmetic expansion
Hello list, maybe something for old stagers. Bash (and POSIX, and Korn, ...) do field/word splitting on the result of arithmetic expansions. This is fine, the behaviour per se is not a problem at all. However, I wonder about the original thought behind it: Is there a specific reason or need to let the shell split an arithmetic expansion result? Or was it just consistency for Korn, "everything is splitted, except the expansions where it makes no sense, like pathname expansion" - should I just take it "as is"? Or even older shells that split everything? Neither the POSIX rationale nor older Korn or shell portability documents I found had any hint about the background - maybe you have? -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Referencing empty array with "set -u" active throws error
jens.schmid...@arcor.de wrote: -u Treat unset variables as an error when substituting. I think the behaviour is consistent with the documentation. The question is rather when to consider a variable set or unset. I'm not sure about the intended meaning here, but I don't consiter $@ as a variable (but a special parameter). Though regarding what Chet said to this topic before, maybe the documentation should be rephrased. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: quotes invade positional parameters
jida...@jidanni.org wrote: Well anyway, it would be 'no skin off of bash's back' if it just reported what it was given. If it was given ' 'a b c it should report ' 'a b c and not just 'assume' we prefer ' a' b c or ' a' 'b' 'c' etc. Just as legitimate and doesn't cause calls in the middle of the night from the old folks home. Wait, that stage of the program doesn't know it was given that, and to make it know would just increase complexity. As would reporting \ \ a b c or would it... OK, never mind. Yea, that's it. It doesn't report what's given, it reports the result of the processing. This is hopefully similar, but definitely not the same. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: nounset option does not work with array in arithmentic expressions
Joerg Boehmer wrote: The value of variable ar[1] is expanded to 0 although it was not set. The full syntax produces the expected behavior: The value of y is 0, since you operate in arithmetic context. This is fine. But I definitely agree it should bail out here. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: quotes invade positional parameters
jida...@jidanni.org wrote: $ cat 201012contract #!/bin/sh -eux set a b c d e f : ''$@'' : ' '$@' ' : ''$*'' : '' $* '' : " "$* " " $ ./201012contract + set a b c d e f + : a b c d e f + : ' a' b c d e 'f ' + : 'a' b c d e 'f' + : '' a b c d e f '' + : ' a' b c d e f ' ' $ apt-show-versions bash bash/unstable uptodate 4.1-3 OK, the problem may only be -x deep, affecting the -x reporting output, but not the actual functionality, thank G.O.D. I'd say this is expected (and by the way it's not only on set -x). -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Referencing empty array with "set -u" active throws error
jens.schmid...@arcor.de wrote: For an empty "$@" this does not throw an "unbound" error, which seems to be an inconsistent behaviour to me. -u Treat unset variables as an error when substituting. I think the behaviour is consistent with the documentation. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: ionice bash pid in bash_profile Fails
Roger wrote: If you want the PID of the current shell process, use $$ instead. Yes I do. It's only me on this computer, unless you're speculating on prioritizing a snooper. :-O This is (in this context) not related to the number pf "bash" processes running. Not at all. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Bug report
sworddrag...@aol.com wrote: Description: It is possible to make input with the keyboard before bash is fully initialized. This problem is critical on password inputs like the linux login. Repeat-By: $input is now shown before and after sworddra...@ubuntu:~$. Example: testsworddra...@ubuntu:~$ test Fix: I think bash should lock all input until it is fully initialized and maybe draw all locked input after unlocking. What makes you think Bash is initialized WHILE you login (and not AFTER)? -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: static vs. dynamic scoping
Eric Blake wrote: In static scoping, function f2 does not shadow a declaration of a, so references to $a within f2 refer to the global variable. The local variable a of f1 can only be accessed within f1; the behavior of f2 is the same no matter how it was reached. If it matters (I already know Chet's answer): I agree with Mr. Korn here about sanity. Infact, for some reason, I always intuitively relied on it (without any problem for now - I didn't hit a case), maybe I intuitively expected the C behaviour from Bash. In Bash practise, now as I know it, I can code accordingly. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Bash bug with ints beyond 2147483646
Greg Wooledge wrote:
On Tue, Nov 02, 2010 at 03:48:49PM -0400, Pete Gregory wrote:
echo {2147483640..2147483647}
dies with a malloc error
In bash 4.1.9 under HP-UX 10.20, it consumes all available CPU until
I kill it with SIGKILL. (I suppose there's a chance it might eventually
have died due to malloc errors or whatever, but after several minutes
of waiting, I got impatient.)
Maybe as an additional hint for Chets debugging: In 3.2.39(1)-release it
works, in 4.1.2(1)-release it fails (yes, Bonsai just came back from
paging...). It drives crazy and mallocs like hell... 32bit int overflow?
--
Be conservative in what you do, be liberal in what you accept from others.
- jbp, master of the net, in RFC793
Re: declare overrides errexit
Sascha Ziemann wrote: The following code prints "a". The second false terminates the script but the first does not. set -e declare a="a"$(false) echo $a b="b"$(false) echo $b The first operation succeeds, the second doesn't. The first operation is the "declare" command, and it works (and will seit its exit code to 0). The second operation is a variable assignment, the status of the variable assignment is != 0. "Workaround": - first declare a - then set a Jan
Re: pwd does not update when path component is renamed
Krzysztof Zelechowski wrote: Description: The text of pwd and the value of $PWD return a cached value, regardless of the actual current path. Repeat-By: mkdir '-p' 'a' && cd 'a' && mv '../a' '../b' && enable '-n' 'pwd' && builtin 'pwd' && pwd Fix: cd '-P' '.' I think it's the same mechanism that catches symlinked directory names, i.e. the shell has its own "view" to the filesystem. For symlinked directories this is not a bug. For this case, I don't think there's a reliable and portable way to catch it. The open directory is valid (since it's open) for the shell process, but $PWD given to other programs will make them fail. But i don't think a getcwd() after every command or every now and then is efficient. The"no solution provided"Bonsai
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
I'm sorry to not answer a message directly, but I didn't get the mails of this list during the last day - no idea why. Quoting text from the pipermail archive. >> After initialÄy introducing =~, Chet made it consistent with =/== >> in a second version, means: =/== doesn't do pattern matching for parts >> inside quotes, =~ doesn't du regexp matching for parts inside quotes. > >Except this isnt' true. Quoting example C: > > t='one two three' > a='one two three' > 1) if [[ $t == $a ]]; then echo 'Matches'; fi > 2) if [[ $t == "$a" ]]; then echo 'Matches'; fi examples. > > The above does match. the pattern in $a matches the pattern > in $t whether it is in quotes or not. > > But with =~ it is different: > t='one two three' > a='one t.. three' > 3) if [[ $t =~ $a ]]; then echo 'Matches'; fi > 4) if [[ $t =~ "$a" ]]; then echo 'SHOULD Match'; else echo 'BUG, double quotes > disable match'; fi Test with a='one t?? three', i.e. use a pattern matching special character. Or for the regex case, use NO regex special character. Then both should behave the same: Patter matching: $ t="one two three" $ a="one t?? three" $ [[ $t = $a ]]; echo $? 0 $ [[ $t = "$a" ]]; echo $? 1 Regular expression matching: $ t="one two three" $ a="one t.. three" $ [[ $t =~ $a ]]; echo $? 0 $ [[ $t =~ "$a" ]]; echo $? 1 Regards, Jan
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Linda Walsh wrote: Why do (or should) double quotes lose their normal meaning inside double brackets? After initialĺy introducing =~, Chet made it consistent with =/== in a second version, means: =/== doesn't do pattern matching for parts inside quotes, =~ doesn't du regexp matching for parts inside quotes. My personal opinion is: This makes sense. Can't speak for others. That's also the reason you have 2 different =~ behaviours. Please, whatever the reasonable result of this discussion is, do not make up yet the next =~ variant that's incompatible with the others ;) I would like to see double quotes and single quotes NOT disable RE functionality when used with =~. I would like to suggest that to disable RE functionality, that the user use '==', instead. == is the same as =, my suggestion is to NOT touch that. It would be even better to introduce a new operator instead of touching =~ (see above) or the pattern matchers. Maybe you don't care for compatiblity, I do, since I'm operating the same scripts on systems with Bash 2.05b to the newest 4.x without changes - so please don't suggest anything that will break compatiblity with very common things that were there for ages (like the pattern matchers in the conditional expression). Wouldn't it be reasonable to do RE matching when one does =~ and not do it when one uses ==? For ==, see above. For the behaviour of =~: It was adjusted in 3.2 to be consistent with =/==. As far as I remember there was a lot of discussion, maybe Chet can say something about it. The whole point of the =~ was to allow regex matching. If you don't want it, why would you have to create special, asymmetric functionality for quotes? I don't really see your problem with regex matching at the moment, maybe I misunderstand you. Maybe you think this means you can not match quotes in a regex at all, this would be totally wrong, of course you can. Just with a small syntax speciality (like for pattern matching, too). The "portable" way for =~ in Bash is putting the RE into a variable, anyways. Not nice. Such things come up when you break compatiblity (see above, changed between 3.0 and 3.2). Regards, Jan
Re: discrepancy with variable assignments and simple commands between sh and bash
Mike Frysinger wrote: On Wednesday, August 25, 2010 00:59:58 Jan Schampera wrote: Mike Frysinger wrote: the difference here being the value in variable "a" after function "f" finishes executing. i was expecting the behavior of `bash`, not of `sh`. i cant seem to find anything covering this in the man page except for perhaps interpreting the meaning of some sections to mean this behavior is allowed. but i certainly didnt locate anything that would imply behavior of this would differ across bash and sh ... I'd expect "VAR=VAL " to behave like in your "bash" example, in any case (i.e. also for functions!). Just intuitively, I mean. I don't know any standard documents about it, maybe it is "implementation defined", as so often. Dash behaves the same way as your "sh" example, Korn too. Z behaves like the "bash" example here. So I fear it actually isn't standardized and you can't operate with functions the same way you operate with separate processes. unfortunately, ive relied on this bash behavior in the past in bash-specific scripts because it's an easy way of tweaking a variable's value for a specific command without having to save/restore context. which is why i was surprised when it didnt work in a #!/bin/sh script (which had sh->bash). not that standards bodies care about the pains they inflict upon me ;). -mike Okay, I think I found something [POSIX excerpts] - When a function is executed, it shall have the syntax-error and variable-assignment properties described for special built-in utilities in the enumerated list at the beginning of Special Built-In Utilities . - Variable assignments specified with special built-in utilities remain in effect after the built-in completes; this shall not be the case with a regular built-in or other utility. [Bash docs about POSIX mode] 24. Assignment statements preceding shell function calls persist in the shell environment after the function returns, as if a POSIX special builtin command had been executed. Conclusion (still waiting for the Austin Group undercover guy): - POSIX specifies this behaviour - Bash in Bash-mode overrides this (which results in intuitive behaviour, IMHO) - Bash in POSIX-mode respects it J.
Re: discrepancy with variable assignments and simple commands between sh and bash
Mike Frysinger wrote: the difference here being the value in variable "a" after function "f" finishes executing. i was expecting the behavior of `bash`, not of `sh`. i cant seem to find anything covering this in the man page except for perhaps interpreting the meaning of some sections to mean this behavior is allowed. but i certainly didnt locate anything that would imply behavior of this would differ across bash and sh ... -mike I'd expect "VAR=VAL " to behave like in your "bash" example, in any case (i.e. also for functions!). Just intuitively, I mean. I don't know any standard documents about it, maybe it is "implementation defined", as so often. Dash behaves the same way as your "sh" example, Korn too. Z behaves like the "bash" example here. So I fear it actually isn't standardized and you can't operate with functions the same way you operate with separate processes. What does Chet, our secret agent in Austin Group, say about this ;-) ? J.
Re: read -d'' -n1
Jan Schampera wrote: 1) Why doesn't this print anything while read -d'' -n1 ch; do echo "$ch" done <<< $'hello\nworld' 2) Why does this print something, but only up to the hyphen? while read -d'' -n1 ch; do echo "$ch" done <<< $'hello\nwor-ld' Please ignore this question. 2 minutes after sending it, I saw my stupid mistake :( Sorry... J.
read -d'' -n1
Hello, don't ask about the detail how I originally invented this code, but I stepped over something I really can't explain: 1) Why doesn't this print anything while read -d'' -n1 ch; do echo "$ch" done <<< $'hello\nworld' 2) Why does this print something, but only up to the hyphen? while read -d'' -n1 ch; do echo "$ch" done <<< $'hello\nwor-ld' Verified on 2.04, 3.2.39, 4.1, so I wonder if I have a misunderstanding here. J.
Re: RFE? request for an "undefined" attribute for functions
Linda Walsh wrote: On 8/2/2010 1:13 PM, Chet Ramey wrote: There are several versions of `autoload' in examples/functions. Chet === I've been using 'man bash' as my reference. I don't see a reference to examples or autoload, and finding 'functions' doesn't show me any examples. Is there another manpage I should be regularly consulting? It's a directory in the Bash distribution. Jan
Re: function grammar
Linda Walsh wrote: The curly brackets are suposed to be optional. They are line "2" of the Compound commands list below... Don't ask me why, but it works when you don't use the "function" keyword, but "()" instead: foo() [[ 1 ]] Might be a parsing bug, though you shouldn't use "function" at all.
Substitution PE parsed wrong or doesn't work correctly
Hello,
Tested versions:
- 4.1.2(1)-release
- 3.2.39(1)-release
Reproduce by:
string="1/2 3="
echo ${string//[= /]}
Expected result:
123
Actual result:
1/2 3=
Workaround: Escape the "inner" slash with a backslash.
Within a bracket expression, the slash should lose its special meaning.
It looks like the construct is incorrectly parsed (because it uses
slashes itself), but I may be wrong, I didn't inspect the code.
Regards,
Jan
Re: Bash cannot kill itself?
Clark J. Wang wrote:
Running a cmd in background (by &) would not create subshell. Simple
testing:
#!/bin/bash
function foo()
{
echo $$
}
echo $$
foo &
### END OF SCRIPT ###
The 2 $$s output the same.
This doesn't mean that it doesn't create a subshell. It creates one,
since it can't replace your foreground process.
It just shows that $$ does what it should do, it reports the relevant
PID of the parent ("main") shell you use. As far as I can see, this
applies to all kinds of subshells like
- explicit ones (...)
- pipeline components
- command substitution
- process substitution
- async shells (like above, running your function)
- ...
J.
Re: Bash cannot kill itself?
Chris F.A. Johnson wrote: $$ refers to the subshell. There's no subshell here, I think. The background process invoked by &. $$ is meant to always report the "main shell", I'd guess this is true for this case, too. J.
Re: RFE: 'list of vars' = split VAR
Linda Walsh wrote: I suppose I'm presuming these features are not already implemented in some fashion -- did I overlook them, or would they be 'new'? I know it's not applicable for all cases, but I usually use read to split strings into variables/an array. J.
Re: A note for read builtin
RESEND FOR THE MAILINGLIST Britton Kerin schrieb: Which in a pipeline is supposed to be the output of the previous command, right? Its not at all obvious to me why it behaves as it does. The other subthread of this thread is about it: In Bash, all parts of a pipeline are executed in an own subshell. This means that the read in the subshell reads the data, sets the variable, and then the subshell is terminated. Regards, Jan
Re: A note for read builtin
Dr. Werner Fink wrote:
The question rises: Why does the bash require a sub peocess/shell
for the final command of a pipe sequence.
I'd think this is more or less a design choice at first (with one or the
other issue, maybe for both solutions - though I can't construct a
failing case for the Korn way at the moment).
From my daily work with automation scripts & Co. (OT: and yes, Werner,
we have SLES ;-) ) I can say this is not a big deal. You have enough
other ways in Bash to give ("pipe") data to the read builtin on the fly.
You don't have any big problems with this behaviour.
Regards,
Jan
Re: A note for read builtin
Britton Kerin wrote: How so? It seems that read always reads from the terminal even when its in a shell pipeline. This isn't correct. Read reads from STDIN by default. Regards, Jan
Re: A note for read builtin
Marc Herbert schrieb: From section 2.12 and from messages posted here in the past I understand that POSIX allows either one. This ambiguity reinforces the need for documentation IMHO. I agree with Greg here, it's a well known "don't". What should be documented is (maybe it is?) how pipelines are implemented in general, the behaviour of read is just a plain consequence of that. Infact I mean that reading a reference manual doesn't avoid learning a language and its behaviours. just my 2ct Jan
Re: Input line length
Oh, and to be complete: uname -rms yields: * Linux 2.6.26-2-amd64 x86_64 The C library is a: * GNU libc 2.16.6-3 The crashed Bash is a: * ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped Jan "TheBonsai"
Re: Input line length
Chet Ramey wrote:
How about a stack traceback?
I'm so sorry, I thought this was clear and easy to reproduce/verify.
I'm using this to generate the script. The number of commands varies
between shell versions (and likely other platform stuff), so you might
need to play around with the values a bit:
{
printf "#!/bin/bash\n"
for ((x=0; x<5; x++)); do printf ":;"; done
echo
} > length.sh
chmod +x length.sh
Attached [bash41_hugeinput.bt.txt] is an excerpt of the backtrace from a
Bash 4.1. The missing middle is always
execute_command_internal()/execute_command().
The original finding was with a Bash 3.2, where the BT looks accordingly.
Regards,
Jan "TheBonsai"
#0 internal_malloc (n=16, file=0x4adee3 "execute_cmd.c", line=289,
flags=) at malloc.c:739
#1 0x0046d827 in sh_xmalloc (bytes=16, file=0x4adee3 "execute_cmd.c",
line=289) at xmalloc.c:183
#2 0x00433174 in new_fd_bitmap (size=32) at execute_cmd.c:289
#3 0x00434c4f in execute_command (command=0x2bf61c8) at
execute_cmd.c:370
#4 0x004348cb in execute_command_internal (command=0x2bf6308,
asynchronous=0, pipe_in=-1, pipe_out=-1,
fds_to_close=0x43ef388) at execute_cmd.c:2229
#5 0x00434c7f in execute_command (command=0x2bf6308) at
execute_cmd.c:375
#6 0x004348cb in execute_command_internal (command=0x2bf6488,
asynchronous=0, pipe_in=-1, pipe_out=-1,
fds_to_close=0x43ef2a8) at execute_cmd.c:2229
#7 0x00434c7f in execute_command (command=0x2bf6488) at
execute_cmd.c:375
#8 0x004348cb in execute_command_internal (command=0x2bf65c8,
asynchronous=0, pipe_in=-1, pipe_out=-1,
fds_to_close=0x43ef1c8) at execute_cmd.c:2229
#9 0x00434c7f in execute_command (command=0x2bf65c8) at
execute_cmd.c:375
...
...
...
#87280 0x004348cb in execute_command_internal (command=0x3a9c548,
asynchronous=0, pipe_in=-1, pipe_out=-1,
fds_to_close=0x3a9cc48) at execute_cmd.c:2229
#87281 0x00434c7f in execute_command (command=0x3a9c548) at
execute_cmd.c:375
#87282 0x004348cb in execute_command_internal (command=0x3a9c6a8,
asynchronous=0, pipe_in=-1, pipe_out=-1,
fds_to_close=0x3a9cb68) at execute_cmd.c:2229
#87283 0x00434c7f in execute_command (command=0x3a9c6a8) at
execute_cmd.c:375
#87284 0x004348cb in execute_command_internal (command=0x3a9c808,
asynchronous=0, pipe_in=-1, pipe_out=-1,
fds_to_close=0x3a9ca88) at execute_cmd.c:2229
#87285 0x00434c7f in execute_command (command=0x3a9c808) at
execute_cmd.c:375
#87286 0x004348cb in execute_command_internal (command=0x3a9c968,
asynchronous=0, pipe_in=-1, pipe_out=-1,
fds_to_close=0x3a9c9a8) at execute_cmd.c:2229
#87287 0x00434c7f in execute_command (command=0x3a9c968) at
execute_cmd.c:375
#87288 0x004216d2 in reader_loop () at eval.c:152
#87289 0x004212d9 in main (argc=2, argv=0x7fffe8469e48,
env=0x7fffe8469e60) at shell.c:749
Re: Input line length
Jan Schampera schrieb: The result of these tests was a SEGV (after some 78K line length). Shouldn't this be sanely catched somehow by the parser? I didn't look deeper, but it looks like a blindly filled buffer or something like that. Sorry, I should make clear that the test case was a bunch of ";"-concatenated echo commands. The line length alone is not a problem (in this test). Jan "TheBonsai"
Input line length
Hello list, somebody in chat just asked about the maximum input line length, I know (and told him) that this might be very platform dependent, but I did some tests. The result of these tests was a SEGV (after some 78K line length). Shouldn't this be sanely catched somehow by the parser? I didn't look deeper, but it looks like a blindly filled buffer or something like that. Anyone? Jan "TheBonsai"
Re: Wrong alignment in select lists
Bernd Eggink wrote:
Select lists are sometimes displayed with incorrect vertical alignment
if an item contains one or more German umlauts. Examples:
select x in äöü blah{1..20}; do :; done# wrong
select x in amöbe blah{1..20}; do :; done# wrong
select x in amöb blah{1..20}; do :; done# wrong
select x in amö blah{1..20}; do :; done# OK
Bash version is 4.1.7(1)-release, LANG is de_DE.UTF-8.
Bernd
It's long ago I since inspected the select code, but I think it's
because it counts bytes for the space calculations. The last one
succeeds because there's a minimum width reached.
J.
Weird behaviour of 'hash' builtin
Hello Chet, hello list, during some discussion in the IRC #bash channel on freenode we found a weird behaviour of the 'hash' builtin command. The command exits true if the operand in question contains a /, no matter if that makes sense or not: --- $ hash 'CHANGELOG_CURRENT="http://slackware.osuosl.org/slackware-current/ChangeLog.txt";'; echo $? 0 --- --- $ hash 'meow/foo/baz'; echo $? 0 --- This alone is weird enough. When you add the -t option (if available) to print the pathname, it fails: --- $ hash -t 'CHANGELOG_CURRENT="http://slackware.osuosl.org/slackware-current/ChangeLog.txt";'; echo $? bash: hash: CHANGELOG_CURRENT="http://slackware.osuosl.org/slackware-current/ChangeLog.txt": not found 1 --- --- $ hash -t 'meow/foo/baz'; echo $? bash: hash: meow/foo/baz: not found 1 --- This happens on a 2.04 (no -t option to check the other case) aswell as on a 4.1. If this is not a bug, what's the reason behind this? Is it to blindly report success when an operand "looks like a pathname"? Regards, Jan "TheBonsai"
Re: Feature request: Can bash provide some mechanism for locking/unlocking?
Clark J. Wang schrieb: > And if the script crashes the dir will be left unlocked. System crashes and kill -9 are the problem. The rest is none. If the area isn't too complex, noclobbered redirection serves well. But if you have other options, they should be used, of course. (doing this on a cluster with a shared fs - does like a charm) J.
Re: Feature request: Can bash provide some mechanism for locking/unlocking?
Clark J. Wang schrieb: > In C code I can use lockf(), flock(), semaphore and mutex for locking / > unlocking. Can bash provide some similar mechanisms? > For simple things, which don't need to be 1000% rocksolid, you can use atomic operations like mkdir or noclobbered redirection for mutex purposes. Accessing the file locking mechanisms of the kernel isn't possible so far, but Bash has a plugin framework. Jan
Re: Undocumented usage of printf?
Clark J. Wang schrieb: > I saw a printf usage from a Linux forum's post: > > # printf "%d\n" "'a" > 97 > # > > It's really cool but I found no info in bash's manual. Are there any other > undocumented interesting features? :) > I "documented" it, though I don't remember where I first heard about it. Maybe I stumbled over it in POSIX (it's specified there). http://bash-hackers.org/wiki/doku.php/commands/builtin/printf#arguments Jan
Re: bash exit command should be unconditional
Vadym Chepkov schrieb: > I would expect never see "Continue" printed The 'exit' command exits the subshell you just created. http://bash-hackers.org/wiki/doku.php/scripting/processtree There's also a FAQ about it, E4. Jan
Re: Crash on completion
Chet Ramey schrieb: > This was reported about five weeks ago, and there's a patch in the pipeline. > I've attached a version for the curious; try it out and let me know. Ah, I had a feeling I alredy read about it somwhere, but I didn't find it quickly, so I thought I was wrong. Thanks, Jan
Crash on completion
Hello list, hello Chet. Bug reported on freenode's IRC #bash by: Satgi There is a crash somewhere in completion (the last commandline is completed using TAB): echo $BASH_VERSION 4.1.2(1)-release mkdir -p the/?/directory ./the/\?/Segmentation fault (core dumped) These completions DO NOT crash there (maybe that's a hint for you): cd the/\?/directory/ cd ./the\?/directory/ Bash was invoked with the --norc option. Tested versions: - 4.1.2: SEGV - 4.1 alpha: SEGV - 4.0.0: SEGV - 3.2.39: OK - 3.2.25: OK So it looks like this was introduced with 4.0. Here's a backtrace I got from a coredump: #0 0x00460fde in command_word_completion_function (hint_text=0x16cd028 "./the/\\?/", state=1) at bashline.c:1692 #1 0x0048c7cb in rl_completion_matches (text=0x16cd028 "./the/\\?/", entry_function=0x460ad0 ) at complete.c:1887 #2 0x004617a2 in bash_default_completion (text=0x16cd028 "./the/\\?/", start=0, end=9, qc=0, compflags=1) at bashline.c:1414 #3 0x00462bba in attempt_shell_completion (text=0x16cd028 "./the/\\?/", start=0, end=9) at bashline.c:1363 #4 0x0048c867 in gen_completion_matches (text=0x16cd028 "./the/\\?/", start=207, end=0, our_func=0x48bff0 , found_quote=-808464433, quote_char=1) at complete.c:1023 #5 0x0048db70 in rl_complete_internal (what_to_do=9) at complete.c:1746 #6 0x00485c63 in _rl_dispatch_subseq (key=9, map=0x6d8d80, got_subseq=0) at readline.c:769 #7 0x00486447 in readline_internal_char () at readline.c:548 #8 0x0048685d in readline (prompt=) at readline.c:575 #9 0x004292ea in yy_readline_get () at /Users/chet/src/bash/src/parse.y:1314 #10 0x00423708 in shell_getc (remove_quoted_newline=1) at /Users/chet/src/bash/src/parse.y:1247 #11 0x00425d45 in read_token (command=) at /Users/chet/src/bash/src/parse.y:2727 #12 0x0042985e in yyparse () at /Users/chet/src/bash/src/parse.y:2360 #13 0x00421102 in parse_command () at eval.c:228 #14 0x004211e6 in read_command () at eval.c:272 #15 0x00421434 in reader_loop () at eval.c:137 #16 0x00420f56 in main (argc=1, argv=0x7fff6ad3f768, env=0x7fff6ad3f778) at shell.c:741 Jan
Re: command not put into history if it starts with space
Mike Frysinger schrieb: >> When using the bash shell in an xterm or rxvt terminals at least, >> commands executed which start with a space, eg " ls" are not added to >> the command line history and so are not accessible by ctrl-p. > > this is by design > -mike This is controlled by the HISTCONTROL and probably HISTIGNORE variables. Unless I misunderstood the question. J.
Re: Error when script uses CRLF line endings w/ if stmt
Andreas Schwab schrieb: >> It's a character like 'A' or 'B'. > > 'A' and 'B' are letters, $'\r' is whitespace. Yes... :)
Re: Error when script uses CRLF line endings w/ if stmt
Evan Driscoll schrieb: > Then, many programs don't handle them per se, but *not* handling them > doesn't cause much problem. grep, cat, and echo probably fall in this > category. Bash doesn't handle it. It's a character like 'A' or 'B'. It causes problems :) J.
Re: Error when script uses CRLF line endings w/ if stmt
Evan Driscoll schrieb: > echo a > echo b > seemed to work with both CRLF and LF endings. However, further > experimentation confirmed what you probably already know, which is that > it only appeared to work; in fact what was happening is that the CR > character was being passed to echo as part of the argument, and it > didn't affect the output. In fact, if you put a space after the 'a' and > 'b', echo receives two arguments beyond the command name: the 'a' or 'b' > as the first and ^M as the second.) Yes, that's exactly what will happen. Personally, I have no problem with the \n-only behaviour (which - in fact - is not Bash specific. Most programs that use text files have trouble when you change to the other world), but that doesn't matter since Chet is the maintainer of Bash, not me ;-) 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. Jan
Re: Error when script uses CRLF line endings w/ if stmt
drisc...@cs.wisc.edu schrieb:
> Some of the time, using CRLF line endings cause syntax errors
> in Bash scripts ("unexpected end of file").
>
> This problem shows up on Bash 4.1 on Linux, Bash 3.2 on Linux,
> and Bash 3.2 on Cygwin (where I first noticed it).
Normal. Though I don't know how to treat the Cygwin case, since the
underlying platform uses \r\n anyways. But the rest: Simply don't mix
UNIX and Windows text.
Re: Selecting out of an array
Jon_R schrieb: > http://old.nabble.com/file/p27316649/newsh2.sh newsh2.sh You have a misunderstanding about select here, I guess. Select is supposed to display a list of given words and take user input (index to these words). It more or less is the same as a for loop, it just doesn't iterate through the words, it lets the user select one of them. http://bash-hackers.org/wiki/doku.php/syntax/ccmd/user_select If you want to make more sophisticated menus, consider to use a dialog(1) or similar: http://mywiki.wooledge.org/BashFAQ/040 Jan
Re: $(pwd) != $(/bin/pwd)
Leonid Evdokimov schrieb: > This problem may be fixed if bash does not optimise number of getcwd() calls, > but I'm not sure if the bug is really a _bug_, but not a sort of strange > feature. Sorry, I didn't read carefully enough :) J.
Re: $(pwd) != $(/bin/pwd)
Leonid Evdokimov schrieb: > This problem may be fixed if bash does not optimise number of getcwd() calls, > but I'm not sure if the bug is really a _bug_, but not a sort of strange > feature. Depends what 'bar' is above, assuming it's a (sym-)link or a bind here: IMHO this is not a bug. There simply is no "one and only absolute path". There's also a nice paper about it from the Plan 9 guys from Bell Labs. J.
Re: command_not_found_handle not called if "command" includes a slash
Ken Irving schrieb: > That's up to that function to determine, since bash passes control over > to it. It should be able to handle whatever it gets. My use case is > to take things that look like 'object.method' -- which are not likely > to collide with normal executables -- and run them under a special handler. > That handler emits an error message and exit code if it can't make sense > of its argument. Yea okay, I just wondered. Of course it's up to the coder. Never mind :) Jan
Re: command_not_found_handle not called if "command" includes a slash
Ken Irving schrieb: >> This patch is not sufficient, as it leaves the error message, but it >> does call the hook function in the problem cases: I'm just not sure if it makes sense. I mean, if the user requests the execution of a *specific file*, what should the hook function do if it fails?
Re: command_not_found_handle not called if "command" includes a slash
Ken Irving schrieb: > Description: > I'm not sure this is a bug, but I notice that the > command_not_found_handle function is not called if the "command" has a > slash in it. I can't find anywhere in the bash source producing the > "No such file ..." error message, so I guess this is being caught > somewhere else before bash gets the command line to process. > > The behavior is not new; a second example is included below from v3.2, > showing the same error message when the bad command looks like a path. > > I'd like to dig into this, to see if there's any hope of hooking into > this case in order to provide a handler, but have no idea where to look. > Is there any hope for this? >From what I can see, the hook function is only triggered when a PATH search returns no result. A given relative or absolute filename doesn't trigger a PATH search.
Re: Query regarding ${parameter:-word} usage
Mun schrieb: > nounset on Something sets -u in your startup scripts (or in the script or whatever)
Re: have bg, fg, but lack stop
jida...@jidanni.org schrieb: > OK, never mind. Market demand too low to add... I rather think you could just define a stop()
Re: IFS handling and read
Lhunath (Maarten B.) schrieb: > My bad. I was under the impression `read` was a Bourne shell-only thing and not standardized under POSIX. (not personal for you only, I see that very often) It would be nice if people actually read POSIX before they talk about it. Jan
Re: <( error
Antonio Macchi schrieb:
> $ hd <(echo -en \\0{0..3}{0..7}{0..7})
>
>
> it breaks the console.
>
>
It doesn't "break the console", it crashes the shell (here with a
subshell to get the text):
bon...@core:~$ bash
bon...@core:~$ hd <(echo -en \\0{0..3}{0..7}{0..7})
malloc: ../bash/subst.c:4198: assertion botched
realloc: start and end chunk sizes differ
last command: hd <(echo -en \\0{0..3}{0..7}{0..7})
Aborting...Abgebrochen (core dumped)
Re: caller builtin returns wrong lineno when sourced
Just for completeness: Same with 3.2.39, 4.1 alpha and beta. Jan
Re: Bash source repository
Chet Ramey schrieb: > That's how I prefer it. I don't do public development on savannah, and > I do controlled test releases. The official patches should be there as individual commits. Though, I admit it's not a small amount of work to do all that for the past releases. Such a GIT or SVN repository technically is easy to do, but who feeds it :( J.
Re: for i in {1..100000...
Antonio Macchi schrieb: > what's the rasonable limit in using this "compact" contruct, after which > the for (( i=0; i<1000...; i++ )) became better? Hardware/OS limits. J.
Re: Test -a and -e
Chet Ramey schrieb: >> Code: >> $ [ ! -a /bin/bash ] && echo "Doesn't exist"; [ -a /bin/bash ] && echo >> "Exists" >> >> Output: >> Doesn't exist >> Exists > Please read the Bash FAQ, question E1. The behavior of test depends on > the number of arguments; the rules are in the manual page. > > Chet "The operators -a and -o are considered binary operators for the purpose of the 3 Arg case." Forgive my ignorance :) Jan
Re: [PATCH] silent job monitor when 'set +m'
Chet Ramey schrieb: > redirect stderr > kill pid > wait pid > restore stderr > > It seems to me that this sequence forces the necessary synchronicity. Interesting. And sad that I never thought of that. Jan
Test -a and -e
Hello list, Code: $ [ ! -e /bin/bash ] && echo "Doesn't exist"; [ -e /bin/bash ] && echo "Exists" Output: Exists Code: $ [ ! -a /bin/bash ] && echo "Doesn't exist"; [ -a /bin/bash ] && echo "Exists" Output: Doesn't exist Exists It seems there's a difference between -a and -e, though they are (as far as I can see) documented to do the same thing. Anybody knows what's going on? May it be confused by the test functionality to default to "non-empty string" and a AND (-a)? Jan
Re: Error handling question
Ciprian Dorin, Craciun schrieb:
> Thus if I say: `set -e ; { false ; true ; }` it works, but when I
> put the `||`, it doesn't...
I think it's because { ...; } isn't a simple command (however, its
components are).
J.
Re: [PATCH] silent job monitor when 'set +m'
Jeff Chua schrieb: > The man page mentioned that 'set -m' should print 'a line containing > their status upon their completion' ... which should imply 'set +m' > should NOT print the status. > > Attached is a patch to 'silent' bash so that it won't print the status > when 'Monitor mode' is off (set +m). > > If this is not the right place to do this, please suggest an alternative > to silent bash when 'kill %!' is executed. > > > Thanks, > Jeff A workaround is to diswon the monster. But yes, I also stumbled over this once. See http://bash-hackers.org/wiki/doku.php/snipplets/kill_bg_job_without_message J.
Documentation issue: Increments in brace expansion
Good morning,
http://www.gnu.org/software/bash/manual/bashref.html#Brace-Expansion
The brace expansion increment syntax is shown wrong.
OLD:
A sequence expression takes the form {x..y[incr]}, where x and y are
either integers or single characters, and incr, an optional increment,
is an integer.
PROPOSED NEW:
A sequence expression takes the form {x..y[..incr]}, where x and y are
either integers or single characters, and incr, an optional increment,
is an integer separated by `..'.
Sorry if this already is fixed in the base documents, I didn't have time
to check deeply.
Jan
Re: 100% cpu with: while true ;do read < /dev/null ;done
Jo King schrieb: > Fix: > [ bash/the read code could > detect there's no stdin and sleep for 1-2 seconds] If you consider this as a bug, the bug is not in Bash (but in the application). In short you request that read should wait a second, once it got a end-of-file signalled, I don't think this is the way to 'fix' this 'bug'. It has far too many side effects or impacts to other uses of read. Fix your application instead, query the exit code of read (non-zero on EOF, timeout or error) and insert a conditional sleep yourself. By the way (not really serious, but it fits): A CPU constantly below 100% is wasted money ;-) Jan
Re: Infinite loop on clearing PWD
Marc Herbert schrieb: >> Repeat-By: >> $ unset PWD > > Fix = readonly PWD ? This is not a fix, this is a workaround. Anyways, I can't reproduce it. J.
Re: $() parsing still broken
Jan Schampera schrieb: It was a "fresh" install. Unpacking source + applying pathces, then build *scratches beard*. And it was done without bison - my bad. Works now. Jan
Re: $() parsing still broken
Andreas Schwab schrieb: Jan Schampera writes: I can reproduce it. What can I do to help tracking it down? Make sure the parser was regenerated after applying patch 1. It was a "fresh" install. Unpacking source + applying pathces, then build *scratches beard*. Jan aka TheBonsai
Re: $() parsing still broken
Hey Chet, I can reproduce it. What can I do to help tracking it down? bon...@core:~/devel/bash-4.0$ ./bash -c 'echo $(echo \|)' ./bash: command substitution: line 1: syntax error near unexpected token `)' ./bash: command substitution: line 1: `echo \|)' bon...@core:~/devel/bash-4.0$ ./bash -c 'echo $BASH_VERSION' 4.0.33(1)-release Jan aka TheBonsai
Re: bug or undocumented feature
Mitch Frazier wrote: > The close appears to be a special case of (from the man page): > >> Similarly, the redirection operator >> >> [n]>&digit- >> >> moves the file descriptor digit to file descriptor n, >> or the standard output (file descriptor 1) if n is not >> specified. > > Not sure if that's a bug or a feature but it should be a feature and > probably should be documented. It's not a bug. It's not undocumented per se, it's in the description of the corresponding input duplication mechanism. It applies to both duplication methods. Jan
Re: bash 4.x filters out environmental variables containing a dot in the name
Christian Krause wrote: > Given all of these facts I still tend to say that the bash shouldn't > filter them... There's always the following argument: "Other characters may be permitted by an implementation; applications shall tolerate the presence of such names." I agree with Christian here. As far as technically possible, Bash should respect every environment variable name. J.
Re: [Feature Request]export extglob from environment
Hello Chet, hello Raph, I was involved in the discussion on IRC (Freenode / #bash) yesterday, maybe I can give one or the other comment. It took a while for us to find out why it happens. When we knew it, and after some discussion, we agreed that the easiest way would be to make Bash able to initialize the shopts from the environment, similar to SHELLOPTS. We discussed other ways, also non-Bash solutions, but they're all more workarounds than solutions. >> - the environment needs extglob > > Not really. In this particular case, you could have used `xterm -e' > to run bash with the -O extglob option. This isn't always possible, easy or even wanted. One of those "workarounds" from above, IMHO. > None of these are compelling. Maybe a BASHOPTS analog to SHELLOPTS > for `shopt' options. It might be useful to provide a configuration > option that defaults extglob to on, also. I'd prefer some own transport variable in environment, like you said. It's not only extglob that isn't transported, though for the rest it doesn't result in syntax errors. Transporting these options would make the behaviour more consistent and less surprising. If a configure option exists or not is more a matter of taste I'd say. But this particular problem would have been solved, yes :) Regards, Jan "TheBonsai" Schampera
Re: Memory leak in for loops
Sandino Araico Sánchez wrote:
>1.
> #!/bin/bash
>2.
>
>3.
> for i in {0..15000} ; do
>4.
> echo $i > /dev/null
>5.
> done
>
>
>
> Repeat-By:
> Run the script above and the process starts leaking memory very
> fast.
>
>
You know what a memory *leak* is, yes? mallocs() without proper free()s.
What you mean is that your memory is used. Feel free to calculate the
memory that is needed to store the string representation of
{0..15000}, I think you will get a number near your RAM size.
J.
Re: Brace expansion
Ray Parrish wrote: > bash: printf: 08: invalid number > 0 > bash: printf: 09: invalid number Arithmetic expression/base specifications: http://bash-hackers.org/wiki/doku.php/syntax/arith_expr#different_bases Seems to apply for all numerical formats for printf, too. J.
Re: feature-request: brief syntax for $(type -p somecommand)
Mike Coleman wrote: > [Oops--I sent that incomplete.] > > It would be nice if there was some really brief syntax for > > $(type -p somecommand) > > I find myself using this all day long with 'ls', 'file', 'ldd', > 'strings', 'nm', etc., and the current incantation is just long enough > to be annoying. > > Mike > > Why do you need to get the path of a program that's in PATH? If you only need to check if it's in PATH then you can use other things, and these in a loop. J.
Re: arithmetic + > + subshell might not be documented
jida...@jidanni.org wrote: > Might not be documented: > > $ cat q > for i in : :; do :|: > x$((++a)); echo =$a=; done; ls x?; rm x? > for i in : :; do : > x$((++b)); echo =$b=; done; ls x?; rm x? > $ bash q > == > == > x1 > =1= > =2= > x1 x2 > > I don't think it's specific to arithmetics. I rather think the redirection (since it's part of the simple command, not the pipeline) happens in the subshell. The side effects affect the arithmetics, of course. J. PS: I don't know if that's worth to document, I would have epxected that behaviour. But I may be wrong anyways.
Re: [bash-bug] contents of whole arrays dissapears leaving while read loop
Dr. Werner Fink wrote: >> This is not a bug, this is a consequence of Bash's design. > > Yep ... nevertheless a side mark: ksh can do ;) Which is: A consequence of Korn's design ;-) *waves the 80km to Nuremberg* Jan
Re: contents of whole arrays dissapears leaving while read loop
Lennart Schultz wrote: > In the construct > cat file|while read line > do > done > the content of any arry assignments in the loop dissapears leaving the loop: This is logic, since every part of the pipe runs in an own subshell (the first one runs in the "current shell"). This behaviour is also *not* limited to arrays. This is not a bug, this is a consequence of Bash's design. You might find hints here: Why? http://bash-hackers.org/wiki/doku.php/scripting/processtree How to do it instead? http://bash-hackers.org/wiki/doku.php/syntax/expansion/proc_subst J.
