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 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 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
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: 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
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: 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: 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 ste...@syslang.net 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: '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: 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
'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
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: 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: 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: 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: 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: 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. Theno solution providedBonsai
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: 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 simple command 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.
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: 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.
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: RFE: 'list of vars' = split expr 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: 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: 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
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
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
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
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; x5; 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=value optimized out) 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
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
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: 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: 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: 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: 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
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 command_word_completion_function) 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 rl_filename_completion_function, 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=value optimized out) 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=value optimized out) 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
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
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
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. 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: $(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: 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: 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: 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; i1000...; i++ )) became better? Hardware/OS limits. J.
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.
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
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: $() 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: 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: 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: 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.
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: Feature Idea: Enhanced Tab Completion
Cam Cope wrote: Combine tab completion with history: when you put ! at the beginning of a command and use tab completion, it displays history results IMHO yet a new history expansion/editing/searching mechanism (there already are a few) would bloat it even more. But that's just my opinion. J.
Re: reference dir ../common in script
OnTheEdge wrote:
I'm trying to check for a directory and create it if it doesn't exist as
follows:
CommonDir=../common
if [ -d ${CommonDir} ]; then
mkdir ${CommonDir}
fi
It works from the command line, but my script doesn't seem to like it and I
can't figure it out.
Thanks for any help,
Duane
You have a wrong logic. This script will mkdir if it exists.
use
[ ! -d ${CommonDir} ]
J.
Re: arguments to script prefixed with -- in debug
lehe wrote: Hi, I am trying to debug my shell script by bashdb. My script take as argument --gdb, so I wrote bashdb myscript.sh --gdb However, this way it will produce error that bashdb: unrecognized option '--gdb' If I quote --gdb as bashdb myscript.sh '--gdb' then I will end up with the quotes as part of my argument. How could I fix this problem? Thanks! I may be wrong (I son't have bashdb...), but what about good old bashdb -- myscript --gdb J.
Re: large exit values (255)
Mike Frysinger wrote: $ true $ echo 'enter ctrl+d $ echo $? 258 $ true $ echo 'enter ctrl+d $ echo 'enter ctrl+c $ echo $? 386 that doesnt seem right to me :) the first test seems fine, and older versions of bash would set 258 for the second test (not sure if it's correct though), but the third test looks like a regression (not clearing exit status completely somewhere ?). -mike Wow - how does one find that out? ;) IMHO everything above 255 is wrong. Maybe it could be fixed by making the $? expansion only respect the lower 8 bits. Though...weird :) (works in Bash 3 and 4 here) J.
Re: large exit values (255)
Mike Frysinger wrote: $ true $ echo 'enter ctrl+d $ echo $? 258 $ true $ echo 'enter ctrl+d $ echo 'enter ctrl+c $ echo $? 386 Just tested it, hopefully it's as easy as changing every itos (last_command_exit_value) to itos (last_command_exit_value 0xFF) in subst.c (seems 2 times). I don't provide a patch because it was a quick look and I don't know if any other parts of the code are involved (if yes, the patch would be awfully wrong). J.
Re: coproc command doesn't accept NAME arg
Tim Hatch wrote: Pilot:~/tmp/bash-4.0 tim$ coproc NAME ls [1] 18474 Pilot:~/tmp/bash-4.0 tim$ ./bash: line 32: NAME: command not found [1]+ Exit 127coproc COPROC NAME ls For some reason it expects a compound command on named coprocesses, http://bash-hackers.org/wiki/doku.php/syntax/keywords/coproc MSGID mailman.4819.1231909794.26697.bug-b...@gnu.org bash(1): If NAME is not supplied, the default name is COPROC. NAME must not be supplied if command is a simple command (see above); otherwise, it is interpreted as the first word of the simple command. Yes, it's not intuitive. Jan
Re: Bash with colors?
Antonio Macchi wrote: commands like ls --color does not use terminfo capabilities... ...use instead fixed strings (without regards about TERMinal) is this a good (and safe) choice too? IMHO not. Too many assumptions. GNU ls seems to always assume an ANSI terminal, regardless which TERM is set. Or did I miss something? I have done a little search about how terminals uses setaf a very very long list of terminals uses the same style of capabilities are maybe the others simply out-of-date? No wonder, 'setaf' is set ANSI foreground IIRC, dedicated to ANSI terminal control. But yes, you're right, most terminals talk ANSI, at least for the most important codes. And for the same reason some people hardcode the dot or the comma as thousands separator in their code, ignoring locale settings. Never seen something different. Alone the fact that STDOUT is a terminal, without knowing which terminal it is, isn't a good base for a decision what to send. I remember alot of stupid MS-DOS applications that blindly relied on running ANSI.SYS CON driver - producing screen output that looked like streusel slices. Just my 2ct J.
Re: Bash with colors?
tal396 wrote: there is any way to echo aaa or any msg in colors? Start at http://bash-hackers.org/wiki/doku.php/scripting/terminalcodes and continue at whatever Google spits out for: - bash colors - terminal colors - ANSI colors - VT100 colors J.
Re: Help: Bash script that show you the last file created?
Mike Frysinger wrote: Without looking there: It can't be documented, because there's no general way to retrieve the creation time of a file. the op wasnt asking for the time, they were asking for the last created file. and the ls man page talks how to sort by ctime. Yes, that's the issue. ctime is not creation time. There is no standard timestamp for file creation. This doesn't exist. Ergo: No way to sort by creation time. J.
Re: if, -n string
coubeatczech wrote: c...@notas:~$ if [ -z $variable ]; then echo true; fi true c...@notas:~$ Can anybody explain to me this behaviour? I would expect not any output in the last command...? The variable is set to zero and there is the condition is still true...? http://bash-hackers.org/wiki/doku.php/commands/classictest#number_of_arguments_rules You'd need some quoting. Jan aka TheBonsai
The colon
Hi. In comp.unix.shell [1] somebody wondered about IFS=: read a b a:b; echo '$a' '$b' ending up in 'a b' '' Korn and Z seem to behave different. I see that across all my available Bash versions. I remember the colon to be special in some way (was it hostnames in a file path?), but I don't know. If this is intended behaviour, can you tell me why (it's gone with quoting/escaping, of course)? J. [1] df5a1262-09ff-4c97-94e8-83a5a046f...@p36g2000prp.googlegroups.com
Re: Bash 4: command_not_found_handle event handler
Jan Schampera wrote: Hello list! Just a few thoughts, awaiting comments. Heh. I wanted to raise a discussion about that issue, but it seems I failed (or I'm the only one who cares) ;) Jan
Re: simple bug/compat question
Linda Walsh wrote: Am running an older bash version and this may be fixed (assuming it is a bug and I'm not confused...:-)) bash version = 3.2.39(20) This works: 1)if [ -n -a 2 -gt 1 ] ; then echo one;fi This does not: 2)if [[ -n -a 2 -gt 1 ]] ; then echo one;fi Shouldn't 2 work equally well as 1? (original test on $1: -n $1 -a $1 -gt 0 ) I don't know if it should be line that, but it definitely isn't the case. This is also (indirectly) described in the manual: There's a section about conditional expressions which holds all the stuff that [ and [[ have in common, then there are individual sections for [[ and test ([) which list /|| for [[ and -a/-o for test. http://bash-hackers.org/wiki/doku.php/syntax/ccmd/conditional_expression /- Do not use the test-typical operators -a and -o for AND and OR, they are not known to the conditional expression. Instead, use the operators and ||. \- Ragards, Jan -- This is my life - this is my net! - Jan
Bash 4: command_not_found_handle event handler
Hello list! Just a few thoughts, awaiting comments. Currently, Bash 4 calls a fixed named function command_not_found_handle() when a command is not found. The basic approach (to have such a possibility) is great, but: I can imagine that there may be more internal events to react on in future. IMHO a more straight forward approach would be to define handlers for named events, similar like you define handlers for signals with 'trap'. Infact, 'trap' already is able to define event handlers, for example EXIT or DEBUG, which aren't signals. The purpose? When - in future - more events should be handled, the current approach ends up in an unsorted and mixed list of handler function names. A common approach for handling internal events would be better. I basically see 3 ways: - extend the 'trap' command to be able to setup (more) event handlers - make up a new command to setup event handlers - (from Plan 9 rc shell signal handling, hehe) define a namespace for function names (e.g. event_). An event handler for the event FOO will be called when it exists, here for example event_FOO() Opinions? Is this point of view completely stupid or is it needed? J.
Re: [bash-testers] Re: case modification operators misbehaviour?
Chet Ramey wrote:
The case modification operators (for parameter expansion) seem to be
puzzled.
Two things I don't understand:
- it seems to work word-wise (might be due to my misinterpretion of the
default pattern)
It does work word-by-word, like the emacs-mode editing commands. I
would like feedback on whether or not that works better than the
alternative.
Intuitively I expected it to operate on the whole content, not word by
word. On the other hand, I have no big clue about emacs and the Bash
emacs-mode, so other people might expect it to work like that.
It doesn't really matter for scripting, because either behaviour can be
used to simulate the other (using a loop etc..).
IMHO the technical more intuitive version (working on the whole content
rather than splitting it into words) should be used. There will be less
surprises for the scripters and less surprises when using fancy
patterns. Also, when it works word by word, it should be 1000% clear
what's treated as a word separator. It took me some time to get it,
because I first experimented with PATH :) Moreover, word separators
might depend on the locale which will have typical locale effects, too.
Again, I think the basic way of seeing the content as a whole is the
clean and straightforward way for the implementation of such an operator.
Much text, but you asked for feedback ;)
I have another one, maybe my misinterpretion or an unclean documentation:
$ TEXT=Test
$ echo ${TEXT^s}
Test
I expected TeSt, since the pattern is s, and the 3rd letter in
Test matches that, and should be changed. Interesting that it works
with ^^s (for Tesst then), but for all s, of course.
It tastes like a bug or a wanted, but non-intuitive implementation.
The vice versa case (tESST and ,S) behaves analog.
--
This is my life - this is my net!
- Jan
Re: Question on bash clearwildcards
grendelos wrote: So this is really bugging me. Why is [a-z] not case sensitive, but [A-Z] is? For example: # ls -l total 0 -rw-r--r-- 1 root root 0 Nov 20 12:22 xa -rw-r--r-- 1 root root 0 Nov 20 12:22 xA # ls -l x[a-z] -rw-r--r-- 1 root root 0 Nov 20 12:22 xa -rw-r--r-- 1 root root 0 Nov 20 12:22 xA # ls -l x[A-Z] -rw-r--r-- 1 root root 0 Nov 20 12:22 xA Any ideas? grendelos This all depends on locales. It's useless to assume that A-Z or a-z is something about the case. See that sequence: AaBbCcDdZz Now think what from A to Z means here. It's all those letters except z. Another sequence: ABCD...abcd... Here, from A to Z means what you *think* it always means. Consider to use [[:aplha:]], [[:upper:]] and [[:lower:]] if possible. J.
Development snapshot
Hello, is there something like a development snapshot for Bash 4 or is the code hidden during development phase and I need to wait for the first release? Thanks in advance, Jan -- This is my life - this is my net! - Jan
Re: feature request: wait --free-slot for poor man's parallelization
Mike Coleman wrote: Here's a bash feature I'd love to see, but don't have time to implement myself: a --free-slot flag to 'wait' that will wait until there is at least one free slot available, where a slot is basically a CPU core. Example usage: $ for ((n=0; n100; n++)); do my_experiment $n $n.out wait --free-slot 4 done which I would run on a quad-CPU host. The meaning of the wait is: if I already have four background invocations of my_experiment running, wait until one finishes, then proceed. (If there are fewer than four running, proceed immediately.) This provides a nice sloppy way of letting me parallelize in a script without having to complicate things. make -j and xargs -P provide some of this capability, but are a lot more work to set up--I'd really like to have this at my fingertips for interactive stuff. I did something like that as a script, using an array of PIDs and a big loop and so on. I don't think it needs to be part of internal Bash features, it wasn't that much work. J.
Re: Bash prints syntax error when command in $(...) contains case-esac
Juergen Gohlke wrote: Description: If a command in $(...) contains a case-esac construction, the bash prints a syntax error instead of executing the code: bash: syntax error near unexpected token `;;' In case you have trouble with code you need, use this workaround: x=$(a=4; case $a in (3) echo a=3;; (4) echo a=4;; esac) And yes, I've also seen this before and I thought it was fixed - maybe I thought of something else. J.
Re: Last modified files with owner / time / permissions
lexton wrote:
From what I read it is not good to use ls -la in the manner I use below.
Could I run this by just using the find command with additional arguments?
I still need to be able to print everything that the ls -la command gives me
GNU find has an -ls option IIRC, which produces output similar to ls -l.
If that's not the case, you can always find ... -exec ls -ld {} \; or so.
J.
Re: function name bug ?
christophe malvasio wrote:
cbz (){ echo why 'cbz' not a valid function name ?;}
bash: syntax error near unexpected token `('
It works for me. What does alias cbz say for you?
alias work
He wants to know if you probably have an alias named cbz defined, not
if your alias engine works.
J.
Re: set -x output of test operator is irretating
Bob Proulx wrote: Chet Ramey wrote: Toralf Förster wrote: I'm wondering why in the example (see below) the right side is prefixed with a '\' wheras the left side is unchanged. ... [EMAIL PROTECTED] ~ $ echo 1 2 3 4 | while read a b c d; do [[ $a = $b || $a = $c || $a = $d ]] echo oops; done + read a b c d + echo '1 2 3 4' + [[ 1 = \2 ]] + [[ 1 = \3 ]] + [[ 1 = \4 ]] Because the ==/!=/= operators are defined to match the rhs as a pattern unless it's quoted. You quoted the original string, and the `set -x' output is supposed to be re-usable as input, so the trace output is quoted appropriately. Of course that makes sense for the == and != cases. But is that true even for the = case? For the = case I thought it was STRING1 = STRING2 and not STRING = PATTERN. When the == and != operators are used, the string to the right of the operator is considered a pattern [...] From the description for [[ ]]. = and == should make have difference in behaviour. J.
Re: set -x output of test operator is irretating
Jan Schampera wrote: = and == should make have difference in behaviour. should not show differences *suh* Sorry J.
Re: Bash substrings: wish for support for negative length (read till n from end)
Richard Neill wrote:
$ echo ${stringZ:2: -1} #Wish: start at 2, read till
ERROR #1 before the end. i.e.
# cde
$ echo ${stringZ: -3: -1} #Wish: start 3 back, read till
ERROR #1 before the end. i.e.
Use (-1), i.e.
$ echo ${stringZ:2:(-1)}
See also
http://bash-hackers.org/wiki/doku.php/syntax/pe#substring_expansion (at
bottom of the section).
J.
