what is wrong here?
Hello, consider the following code: EXTENSION=jpg INPUT_FILES=*.$EXTENSION if [ -z $INPUT_FILES ]; then echo No .$EXTENSION input files in this directory exit -1 fi Consider a dir with some .jpg files. the if close is not executed. This is correct. Consider now a dir without .jpg files. Then the if close also isn't executed, while it should. The script isn't exited and runs further with all wrong actions as consequence. What is wrong here? Best regards, Francky Leyn
Re: what is wrong here?
Am 08.08.2011 14:17, schrieb mhenn: Am 08.08.2011 11:33, schrieb Francky Leyn: [...] echo $INPUT_FILES #obviously wrong #instead maybe INPUT_FILES=$(ls *.$EXTENSION) [...] That actually wasn't such a good advice: http://mywiki.wooledge.org/ParsingLs Better use find or or a for loop like this: for file in *.$EXTENSION; do ... #but attention here: if no such a file exists, # $file is *.jpg (with a literal asterisk) #maybe break after the first found file? done
Re: what is wrong here?
Am 08.08.2011 15:22, schrieb Francky Leyn: On 8/8/2011 2:17 PM, mhenn wrote: Am 08.08.2011 11:33, schrieb Francky Leyn: Hello, consider the following code: EXTENSION=jpg INPUT_FILES=*.$EXTENSION echo $INPUT_FILES #obviously wrong #instead maybe INPUT_FILES=$(ls *.$EXTENSION) I tried something similar: INPUT_FILES=`ls *.$EXTENSION` This worked when there were files. But when there were no matching files, it didn't. In that case the words of the ls error message were considered as files, which is obviously wrong. I'm new to bash, and have never seen a construct like yours. Could you briefly explain what the dollar and the () mean (subshell)? `stuff` also creates a subshell :) and $(stuff) actually does the same. See man bash | less -p '\$\(command' Btw: how can I get rid off the ls error message in your construct? I tried already by postponing with /dev/null, and 2/dev/null, but that all doesn't help. Is ls writting to /dev/tty? and in that case, how can I suppress the ls error message? INPUT_FILES=$(ls *.$EXTENSION 2/dev/null) if [ -z $INPUT_FILES ]; then echo no such file; fi Anyway, your construct works fine for files without spaces or newlines. Now up to the link you have me. Thanks for the help! np
I/O bug with big file?
Hi all, Here is a small test which shows what happens: limit=5; x=1; while [ $x -le $limit ]; do printf %010d\n $x; x=$(( $x + 1)); done bigfile.txt while read line; do echo -e TEST\t$line; done bug.txt Basically the first line creates a big 5Gb text file containing 500 millions numbered lines (no problem here). Then the second line reads this file line by line and adds a prefix 'TEST' to each. The problem is that after the line 0195225788, it goes wrong and loops on the following sequence: TEST 0195225788 TEST 225778 TEST 0195225779 TEST 0195225780 TEST 0195225781 TEST 0195225782 TEST 0195225783 TEST 0195225784 TEST 0195225785 TEST 0195225786 TEST 0195225787 TEST 0195225788 TEST 225778 (so don't forget to stop the script, the bug.txt file will grow infinitely!) tested on an Ubuntu 11.04: uname -a Linux bloom 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux bash --version GNU bash, version 4.2.8(1)-release (i686-pc-linux-gnu) I posted this issue yesterday in the Ubuntu forums, the problem was confirmed by another user: http://ubuntuforums.org/showthread.php?t=1808384 Regards Erwan
Behavior of calling return from a trap
Hi all,
I'm noticing some odd behavior in an ERR trap with errtrace. It's
present in bash 3.2 and as well as 4.2. The simplest reproduction is
as follows:
--8--
#!/bin/bash
somefunc() {
false
echo shouldn't see this
}
set -E
trap -- 'return 1' ERR
somefunc
echo should see this
--8--
Both versions of bash throw an error, though fwiw the line number
differs: bash4 blames the line of where the trap is fired versus bash3
which blames the line where the trap is declared. The entire output of
the script is:
foo: line 4: return: can only `return' from a function or sourced
script
should see this
So, both versions give the intended behavior of returning from the
function despite the error. imo, there's a bug here somewhere, I'm
just not sure if it's the faulty error being thrown or if I shouldn't
be expecting the trap to work as it is when it's declared outside of a
function.
Regards,
Dave
Re: Edit vs delete a running script. Why difference?
On Jan 18, 5:22 am, Greg Wooledge wool...@eeg.ccf.org wrote: On Wed, Jan 18, 2012 at 01:19:20PM +0900, Teika Kazura wrote: If the entire script is read at invocation, then why should / does modification affect? Is it a bug? The entire script *isn't* read at invocation. Bash just reads a little bit at a time, as needed. Interestingly, on many Linux systems this allows one to check (crudely) how far a script has progressed by looking at /proc/pid/ fdinfo/255.
Re: what is wrong here?
On Mon, Aug 08, 2011 at 03:41:52PM +0200, mhenn wrote: Am 08.08.2011 15:22, schrieb Francky Leyn: On 8/8/2011 2:17 PM, mhenn wrote: Am 08.08.2011 11:33, schrieb Francky Leyn: consider the following code: EXTENSION=jpg INPUT_FILES=*.$EXTENSION echo $INPUT_FILES #obviously wrong #instead maybe INPUT_FILES=$(ls *.$EXTENSION) They are both incorrect. If you want a list of all the files that match a glob, use an array to hold them: files=(*.$extension) Parameter expansion ($extension) happens before globbing (*.jpg), and the results will be placed into an array. Filenames with whitespace will be handled correctly. This worked when there were files. But when there were no matching files, it didn't. If you want the array to be empty when there are no matching files, then you must enable bash's nullglob option: shopt -s nullglob files=(*.$extension) See also http://mywiki.wooledge.org/BashFAQ/004 (checking/counting files) and http://mywiki.wooledge.org/BashFAQ/005 (arrays) and http://mywiki.wooledge.org/glob(globs) Using ls in a script is almost always wrong, unless you're simply dumping its output to a terminal for a human to read. Use globs instead.
initialisation bash variables
Hello, if you have a variable, say VAR, and you don't assign it a value, and afterwards you test it, what is the value of $VAR then? random, or an empty string? Best regards, Francky
Re: shopt can't set extglob in a sub-shell?
On 02/26/12 12:41, John Kearney wrote: I updated that wiki page Hopefully its clearer now. http://mywiki.wooledge.org/glob#extglob Valuable information. I wonder if some of it should be included in the user manual, at least to point out some possible misbehaviours one wouldn't expect.
Re: Syntax Question...
On 18.08.2011 12:44, Stephane CHAZELAS wrote:
2011-08-17, 08:24(-04), Greg Wooledge:
On Tue, Aug 16, 2011 at 03:41:19PM -0700, Linda Walsh wrote:
Ken Irving wrote:
Maybe this?
today_snaps=( ${snap_prefix} )
but as you mention, that will put them into an arraysorry imprecise
terminology list for me is some number of objects in a string
separated by some
separator.
This is an extremely bad idea. Legacy Bourne shell code from the
1980s kind of bad -- from the horrible days before we *had* arrays
in shells. How are you going to handle filenames with spaces in them?
With newlines in them? With commas in them? With colons in them? Tabs?
DEL characters? Those are all valid in filenames. Any delimiter you
can *put* in a shell string is also a valid character in a filename (or
at least in a pathname, which eliminates the possibility of using slash).
In this code:
today_snaps=( ${snap_prefix} )
With the default value of IFS in bash and without globbing
disabled, the problematic characters are SPC, TAB, NL, *, ?, [
and potentially more if you have extended globbing enabled.
I think this works! You're missing the context or something.
snap_prefix is a shell glob pattern here, ending in *.
$ touch ' ' $'\t' $'\n' '*' '?' '['
$ snap_prefix=* # no glob happening here!
$ today_snaps=( ${snap_prefix} ) # glob happening here and
# the results are assigned to the
# elements of the today_snaps array
$ for e in ${l[@]}; do stat -c%N $e; done
`\t'
`\n'
` '
`*'
`?'
`['
I don't see a problem...
Writing to bash's tty too fast: workarounds?
I'm the maintainer of a terminal emulator on Mac OS and a user reported that if he pastes a large string of the form: cat EOF whatever.txt blah blah blah blah blah blah ... etc for 100k ... EOF That the output is badly mangled. I can reproduce this consistently with a smallish test program. Having traced into readline, the culprit seems to be that readline fiddles with the terminal between lines of input (I'm pretty sure the things done in set_tty_settings() are responsible, but I haven't proved it yet). This seems to cause it to drop some or all of the input that's in the input buffer. Is this a known issue? I can reproduce it on Linux as well, but it's much less severe. The test case can be found here: http://pastebin.com/as3KjEcq To build on Mac, compile with gcc bug.c -o bug -DMACOS To build on Linux: gcc bug.c /usr/lib/libutil.a -o bug It should produce a file in your home directory called mytestfile.txt that looks like this: ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXY ZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWX YZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVW etc. On Linux, you get the occasional short line. On Mac OS, you get only a few lines and they're very long. I can reproduce this on Mac OS with the latest bash source build with default settings. Thanks for your help, George
Re: incompatibility in regex
On Mon, Oct 10, 2011 at 08:06:17PM +0200, Peter Schreiber wrote: 3.1.17(1)-release: - [[ a =~ a|b ]] echo true -bash: syntax error in conditional expression: unexpected token `|' - [[ a =~ a\|b ]] echo true # that one works in version 3 true === 4.1.10(4)-release: - [[ a =~ a\|b ]] echo true # ... but not in version 4 - [[ a =~ a|b ]] echo true true Do I really need to check BASH_VERSION first? Always store the regular expression that you intend to use on the right hand side of =~ in a variable. re='a|b' if [[ $a =~ $re ]]; then ... That is the only way to be sure it will work in whatever version of bash you happen to be using.
print function in bashsource/examples/functions/kshenv
This is not a bug in bash itself, but I was wondering if there are any updates to the ksh-compatibility print function provided with bash in the source distribution (in the examples/functions/kshenv file), specifically with regards to ksh-compatible handling of -R. Using ksh: $ print -R -z -z Using bash 4.2.10 with the kshenv file: $ print -R -z bash: illegal option -- z My understanding is that the -R should disable further option processing except for -n, and display any additional arguments, including those beginning with - I have worked around the problem to some extent by modifying the function, but was wondering if anyone has a more accurate/efficient/ official/distributed version. Thanks. Paul
Re: {varname} for redirection does not work with arrays
On Nov 5, 12:34 pm, Stephane CHAZELAS stephane_chaze...@yahoo.fr
wrote:
2011-11-2, 12:01(-06), unkn...@vmw-les.eng.vmware.com:
[...] Description:
If {varname} is an assoc. array in a redirection the exec will fail
The [] should not be confused with pathname expansion just like ${}.
Repeat-By:
$ declare -A array
$ exec {array[key]}file
[...]
In the documentation, it's {VARNAME}file, so bash works as
documented.
zsh doesn't support {array[key]}file either.
ksh does though it's not documented (documented the same as
bash).
The work around is easy though:
$ declare -A array
$ exec {var}file
$ array[key]=$var
--
Stephane
Hello Stephane,
The workaround is trivial, its just inconsistent (with other parts
of bash).
I can say:
$ declare -A array
$ read -r 'array[key]' 'foo'
This also makes arrays more directly useful.
$ declare -A fd
$ local fifo
$ exec {fifo}${fifo_path}
$ fd[fifo]=${fifo}
$ unset fifo
becomes
$ declare -A fd
$ exec {fd[fifo]}${fifo_path}
Syntax coloring/highlighting in gnu-readline
Hi From my understanding of http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html it's OK to ask gnu-readline questions in this list. I'm trying to interactively add colors while typing in readline and using rl_event_hook to change rl_line_buffer seems to work. Alas the ANSI escape codes for formatting which are allowed in the prompt are not interpreted and shown as they are. I learned from the old discussions I googled entering formatting code would confuse cursor point and history entries. Any other approach to achieve this? Maybe a hook which does the final printing when a line is displayed, where I could inject colors? Cheers Rolf
Re: how to write this in bash
Am 05.08.2011 17:47, schrieb Maverick:
I also tried already
$CMD || echo 'Error...' exit -1
see
man bash | less -p Compound
$CMD || { echo 'Error...'; exit -1; }
Re: excess braces ignored: bug or feature ?
On 02/17/12 20:51, Mike Frysinger wrote:
FOO= BAR=bar
: ${FOO:=${BAR}
echo $FOO
Why should this be a bug? Your second line performs a parameter
expansion, all the remaining characters are joint into the token and
passed to ':'.
No bug.
Re: initialisation bash variables
On 8/15/2011 9:24 PM, Stephane CHAZELAS wrote: 2011-08-15, 17:15(+02), Francky Leyn: Hello, if you have a variable, say VAR, and you don't assign it a value, and afterwards you test it, what is the value of $VAR then? random, or an empty string? [...] Upon startup, the shell makes one shell variable per environment variable whose name is compatible with shell variable names. So for instance, if bash receives VAR=foo in its environemt, $VAR will expand to foo. If it's passed 1=bar, $1 will not be affected, and it's the same for a few special variables of the shell. If passed A+B=C or =D for instance, that obviously won't be mapped to shell variables. Some shells do discard variables from the environment that can't be mapped to shell variables. That's not the case of bash. If you don't initialise a sh/bash variable, and ask it up afterwards, which value does it have then? Is that random or the empty string? At the moment I'm doing the following: VAR=FALSE # some command line procesing, that can set VAR to TRUE if [ $VAR = TRUE ]; then ... fi Must I effectively write that VAR=FALSE? Or will the script work fine without? Also, can't I write the test as if [ $VAR ]; then ... fi Regards, Francky
Re: bash-4.2, crosscompiling and job control compile failure
On Sep 15, 9:20 am, Chet Ramey chet.ra...@case.edu wrote:
On 9/14/11 4:57 PM, Maciej Grela wrote:
In which tarball will your fix be released ? I don't understand the
code flow between the tarballs and git on savannah, the git repo
contains only imports from tarballs until 4.0, and the newest tarball
is 4.2.
It will come out as part of bash-4.3. It may be released as a patch to
bash-4.2, but, based on the number of reports, it's not a high-priority
issue.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
Chet,
I tried to cross compile with arm toolchain.
Would you please have a check if the following patch is proper?
Thanks!
diff --git a/execute_cmd.c b/execute_cmd.c
index 485b0c7..20be69a 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -2202,7 +2202,11 @@ execute_pipeline (command, asynchronous,
pipe_in, pipe_out, fds_to_close)
/* If the `lastpipe' option is set with shopt, and job control is
not
enabled, execute the last element of non-async pipelines in the
current shell environment. */
+#if defined (JOB_CONTROL)
if (lastpipe_opt job_control == 0 asynchronous == 0
pipe_out == NO_PIPE prev 0)
+#else
+ if (lastpipe_opt asynchronous == 0 pipe_out == NO_PIPE
prev 0)
+#endif
{
lstdin = move_to_high_fd (0, 0, 255);
if (lstdin 0)
Please... No Racing with the Planes
'Philadelphia International Airport shut down temporarily Thursday morning after a civilian drove onto the runway.'... More on story here[http://tothecenter.com/2012/03/philadelphia-airport-shut-down-for- car-on-the-runway/].
Re: String behaviour
On Fri, Jun 24, 2011 at 10:38, BX daide...@gmail.com wrote:
#/bin/bash
# file1
import()
{
source file2
}
import
echo v1=$v1, v2=$v2, v3=$v3
#/bin/bash
# file2
v1=v1
declare -x v2=v2
declare v3=v3
Run above script by
$ bash file1
Expected result: v1=v1, v2=v2, v3=v3
Real result: v1=v1, v2=, v3=
From the documentation here:
info '(bash)Shell Functions'
we have:
When the name of a shell function is used as a
simple command name, the list of commands
associated with that function name is executed.
Shell functions are executed in the current shell
context; no new process is created to interpret
them.
...
The BODY of the function is the compound
command COMPOUND-COMMAND
and from:
info '(bash)Command Grouping'
we have:
Placing a list of commands between curly braces
causes the list to be executed in the current
shell context. No subshell is created.
and from:
info '(bash)Bourne Shell Builtins'
we know that the `source' builtin works as follows:
Read and execute commands from the FILENAME
argument in the current shell context
and from:
info '(bash)Bash Builtins'
we have
When used in a function, `declare' makes each
NAME local, as with the `local' command, unless
the `-g' option is used.
So, basically, the results are as expected: You execute the function
`import', which executes `source file2' in the current shell context,
which creates the variable `v1' in the current shell context, but
creates the variables `v2' and `v3' local to the function being
executed in the current shell context, so that by the echo statement,
only `v1' is defined.
Sincerely,
Michael Witten
Re: bash-4.2, crosscompiling and job control compile failure
On 9/16/11 12:35 PM, bigbigboy wrote: On Sep 15, 9:20 am, Chet Ramey chet.ra...@case.edu wrote: On 9/14/11 4:57 PM, Maciej Grela wrote: In which tarball will your fix be released ? I don't understand the code flow between the tarballs and git on savannah, the git repo contains only imports from tarballs until 4.0, and the newest tarball is 4.2. It will come out as part of bash-4.3. It may be released as a patch to bash-4.2, but, based on the number of reports, it's not a high-priority issue. This came out as bash-4.2 patch 18. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: print function in bashsource/examples/functions/kshenv
On 8/20/11 11:17 PM, Paul Tibbitts wrote: This is not a bug in bash itself, but I was wondering if there are any updates to the ksh-compatibility print function provided with bash in the source distribution (in the examples/functions/kshenv file), specifically with regards to ksh-compatible handling of -R. Using ksh: $ print -R -z -z Using bash 4.2.10 with the kshenv file: $ print -R -z bash: illegal option -- z My understanding is that the -R should disable further option processing except for -n, and display any additional arguments, including those beginning with - I have worked around the problem to some extent by modifying the function, but was wondering if anyone has a more accurate/efficient/ official/distributed version. If you have improvements to the function, please send them to me and I will incorporate them into the bash distribution. There's nothing official about those functions; they're just examples. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bug fix for $((x**y)) algorithm on 64+ bits machines.
On 9/19/11 2:35 PM, Stephane CHAZELAS wrote: FYI, ksh93 uses pow(3). So does zsh, but only in floating point mode. Probably better and more efficient than reinventing the wheel. Maybe, but since bash doesn't use floating point arithmetic, probably not. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: COMP_POINT is not set correctly when there is non-ascii characters in the command line.
On Wed, Mar 28, 2012 at 10:48 PM, Chet Ramey chet.ra...@case.edu wrote:
On 3/27/12 2:17 PM, Yichao Yu wrote:
So is it possible to set COMP_POINT as the number of characters
between 0 and rl_point (if it is also bad to break libreadline api by
setting rl_point as that.) without screwing up other part of the code?
(I hope this fix would be no more than searching for rl_point and
replace wherever necessary.)
I was going to respond that to break the relationship between COMP_POINT
and rl_point makes it very difficult, if not impossible, to identify the
character under the cursor when completion is attempted, but I'm not
sure how much that actually matters. You can't assign rl_point using
this, so that's not an issue either.
Sorry didn't get it. Bash can always internally access rl_point (to
identify the character under the cursor) whether or not it is the
same with COMP_POINT and the script CANNOT identify the character
under the cursor using current value of COMP_POINT since
${COMPLINE:blah:blah} substitution count character instead of byte.
And this really matters, see the bash-completion bug report I link
below.
(Agree that rl_point should be kept the locale independent byte
counting value as what it is now.)
Pretty much everything else in bash uses characters, which may be bytes
depending on the locale.
Can someone who's more familiar with the bash completion package tell me
whether or not it uses COMP_POINT at all? That's about that only thing
I can think of that would use it.
It DOES use COMP_POINT. And this is the most annoy thing and also how
I notice the issue. I reported a bug for bash-completion here
(https://alioth.debian.org/tracker/?func=detailatid=413095aid=313583group_id=100114)
and soon discovered this is a bush issue.
Yichao Yu
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
