Mapfile callback access to current line
Mapfile would be that much more powerful if the callback function had access to the current line. Is there any chance this might be added in the future?
Re: string to integer
On Apr 2, 8:19 am, Javier Montoya wrote:
> On Mar 19, 6:04 pm, DennisW wrote:
>
>
>
>
>
> > On Mar 19, 6:50 am, Javier Montoya wrote:
>
> > > On Mar 19, 12:39 pm, Javier Montoya wrote:
>
> > > > Dear all,
>
> > > > I have a several directories with *.jpg images. The image files are
> > > > named as ascending numbers and I would like to retrieve the lowest and
> > > > largest image number in each directory. An example of the content of a
> > > > directory is given below:
> > > > /bla/bla/bla/dir1
> > > > -> 0.jpg
> > > > -> 1.jpg
> > > > ->
> > > > -> 09001.jpg
>
> > > > The desired output would be the integer numbers: 0 and 9001
> > > > With the code below, I'm able to retrieve in "seqInterval" array,
> > > > which is the lowest and largest image number as strings.
> > > > seqDir="/bla/bla/bla/dir1"
> > > > seqInterval=($(find $seqDir -name "*.jpg" | sort | sed -n -e '1p;$p' |
> > > > sed -e 's|^.*/||' -e 's/\.[^.]*$//'))
> > > > in our example, I obtain sth. like:
> > > > seqInterval[0] is equal to "0" and seqInterval[1] is equal to
> > > > "09001"
> > > > Since those are string numbers, I was wondering which is the best way
> > > > to convert those strings into integer numbers (seqInterval[0]=0 and
> > > > seqInterval[1]=9001)?
>
> > > > I tried the code below, but it doesn't work properly, any suggestions?
> > > > startImg=$(printf '%d' ${seqInterval[0]})
> > > > endImg=$((printf '%d' ${seqInterval[1]}))
>
> > > > Best whishes
>
> > > Dear all,
>
> > > I found a solution:
>
> > > startImg=$(printf '%d' ${seqInterval[0]//0/})
> > > endImg=$(printf '%d' ${seqInterval[1]//0/})
>
> > > Is there's a better way, pls let me know!
>
> > In the case of 09001 your command results in "91"
>
> > Try:
>
> > shopt -s extglob
> > printf '%d' ${seqInterval[0]/#*(0)/}
> > printf '%d' ${seqInterval[1]/#*(0)/}
>
> > which says "delete a sequence of zero or more '*()' zeros anchored at
> > the beginning '#' of the string"
>
> Thanks Dennis! But in the case of 00, I obtain an empty value.
> Ideally, I should keep just one zero.
>
> Best wishes
$ shopt -s extglob
$ declare -a
seqInterval='([0]="00" [1]="01" [2]="009001" [3]="390001")'
$ for i in {0..3}; do printf '%d\n' ${seqInterval[i]/#*(0)/}; done
0
1
9001
390001
Tested in Bash versions 3.2.49(23)-release and 4.0.33(1)-release.
Re: string to integer
On Mar 19, 6:50 am, Javier Montoya wrote:
> On Mar 19, 12:39 pm, Javier Montoya wrote:
>
>
>
>
>
> > Dear all,
>
> > I have a several directories with *.jpg images. The image files are
> > named as ascending numbers and I would like to retrieve the lowest and
> > largest image number in each directory. An example of the content of a
> > directory is given below:
> > /bla/bla/bla/dir1
> > -> 0.jpg
> > -> 1.jpg
> > ->
> > -> 09001.jpg
>
> > The desired output would be the integer numbers: 0 and 9001
> > With the code below, I'm able to retrieve in "seqInterval" array,
> > which is the lowest and largest image number as strings.
> > seqDir="/bla/bla/bla/dir1"
> > seqInterval=($(find $seqDir -name "*.jpg" | sort | sed -n -e '1p;$p' |
> > sed -e 's|^.*/||' -e 's/\.[^.]*$//'))
> > in our example, I obtain sth. like:
> > seqInterval[0] is equal to "0" and seqInterval[1] is equal to
> > "09001"
> > Since those are string numbers, I was wondering which is the best way
> > to convert those strings into integer numbers (seqInterval[0]=0 and
> > seqInterval[1]=9001)?
>
> > I tried the code below, but it doesn't work properly, any suggestions?
> > startImg=$(printf '%d' ${seqInterval[0]})
> > endImg=$((printf '%d' ${seqInterval[1]}))
>
> > Best whishes
>
> Dear all,
>
> I found a solution:
>
> startImg=$(printf '%d' ${seqInterval[0]//0/})
> endImg=$(printf '%d' ${seqInterval[1]//0/})
>
> Is there's a better way, pls let me know!
In the case of 09001 your command results in "91"
Try:
shopt -s extglob
printf '%d' ${seqInterval[0]/#*(0)/}
printf '%d' ${seqInterval[1]/#*(0)/}
which says "delete a sequence of zero or more '*()' zeros anchored at
the beginning '#' of the string"
Re: Why tab is not colored?
On Mar 7, 10:20 am, Peng Yu wrote: > My grep is aliased to "grep --color=auto". > > I then use grep "", where is a tab character. But the > result is not colored. How to make the tabs colored? If you grep for a space or a newline, they don't get highlighted either. That's just the way it works. To colorize "whitespace" grep would have to set the background color. Also, as Bob said, this is a Bash list, not a grep one.
Re: Confused about how bash breaks input into words
On Feb 23, 8:41 pm, Allen Halsey wrote: > Eric Blake redhat.com> writes: > > > > > But you missed that: > > > $(date +'%Y-%m-%d') > > > is an entire word (basically, an unquoted $ character consumes until the > > end of the shell substitution, command substitution, or arithmetic > > substitution, and that entire scan becomes part of the current word being > > parsed). > > Thank you Eric and Chris. > > The link to the POSIX section on Token Recognition really helped my > understanding. > > I don't think I missed anything in the Bash Reference Manual that > explains this. > > Allen >From the Bash info-file: "The order of expansions is: brace expansion, tilde expansion, parameter, variable, and arithmetic expansion and command substitution (done in a left-to-right fashion), word splitting, and filename expansion." So command substitution is performed before word splitting.
Re: declare -c still undocumented.
On Feb 12, 2:10 am, Mikael Fridh wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include
> -I../bash/lib -g -O2 -Wall
> uname output: Linux teheran 2.6.31-19-generic #56-Ubuntu SMP Thu Jan
> 28 02:39:34 UTC 2010 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.0
> Patch Level: 33
> Release Status: release
>
> Description:
> declare: usage: declare [-aAfFilrtux] [-p] [name[=value] ...]
> mik...@teheran:~$ declare -c moo=moo; echo $moo
> Moo
>
> Repeat-By:
> run declare -c
>
> Fix:
> document in bash(1), document in usage:, add to builtin help.
Also, toggle case by word ${PARAMETER~PATTERN} and toggle case all $
{PARAMETER~~PATTERN} are undocumented.
Re: Circulate matches in command completion?
On Feb 11, 11:33 am, Peng Yu wrote: > On Thu, Feb 11, 2010 at 10:36 AM, Chet Ramey wrote: > > On 2/11/10 11:05 AM, Peng Yu wrote: > >> On Thu, Feb 11, 2010 at 9:58 AM, Chet Ramey wrote: > >>> On 2/11/10 10:54 AM, Peng Yu wrote: > Suppose I file 'a1.txt' and 'a2.txt' in my current directory. When I > type 'cat a' then TAB, it will show me 'a1.txt' and 'a2.txt'. If I > type TAB repeatedly, it will always show me the same thing. > > However, a better response might be > 1. complete the command to 'cat a1.txt' at the 2nd TAB, > 2. complete the command to 'cat a2.txt' at the 3rd TAB, > 3. return to the original 'cat a' at the 4th TAB, > 4. complete the command to 'cat a1.txt' again at the 5th TAB. > > I'm wondering if there is a way to configure bash this way. > > >>> bind 'TAB:menu-complete' > > >> This is helpful. But it is not exactly what I'm looking for. I still > >> want to show 'a1.txt' and 'a2.txt' at the 1st TAB. The above bind > >> command gives me 'cat a1.txt' directly at the 1st TAB. > > > Look at the 'show-all-if-ambiguous' option. The combination may do what > > you want. > > set show-all-if-ambiguous On > bind 'TAB:menu-complete' > > I typed in the above two commands. It seems that command completion is > the same as if I only typed in the second command. Do you know why? The first command should be: bind 'set show-all-if-ambiguous On'
Re: + vs. [^/]* - Regular Expression bug?
On Feb 8, 11:38 pm, Morten Lauritsen Khodabocus
wrote:
> Hello,
>
> Ran into some particular behaviour with REs in bash, I just cannot
> understand how this could possibly be correct behaviour. Then again, I
> am no bash guru, could very well be me missing a clue.
>
> If I am wasting your time, sincere apologies.
>
> I am not subscribed to the list, so please include my email explicitly
> in any replies that you would like me to read / respond to.
>
> Thanks a million for a great shell! Beers are on me next time any of you
> are in Zurich.
>
> Here's the bashbug description:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include
> -I../bash/lib -g -O2 -Wall
> uname output: Linux sony2 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28
> 01:26:53 UTC 2010 i686 GNU/Linux
> Machine Type: i486-pc-linux-gnu
>
> Bash Version: 4.0
> Patch Level: 33
> Release Status: release
>
> Description:
> Two regular expressions should match the same thing, but for some reason
> do not:
> [[ '/home/' =~ [^/]+ ]]; echo ${bash_remat...@]}
> and
> [[ '/home/' =~ [^/]* ]]; echo ${bash_remat...@]}
> the first matches 'home', the second matches nothing. The only
> difference is * vs. + AFAICT, both expressions should match 'home'.
>
> Repeat-By:
> Simply evaluate the two lines from the description.
>
> Thanks again,
> Morten
* means zero or more characters. It found zero and stopped. You could
do:
[[ '/home/' =~ /([^/]*) ]]; echo ${BASH_REMATCH[1]}
Re: Bug with -o posix, local variables and assignment preceding builtins
On Feb 7, 7:33 pm, Crestez Dan Leonard wrote:
> We encountered a strange bug while working on bash-completion. I was
> originally only able to reproduce this through a fairly elaborate setup
> but Freddy Vulto found a tiny test case:
>
> set -o posix
> t() {
> local x
> BAR=a eval true
> }
> BAR=b; t; echo $BAR
>
> Bash documentation claims the following (section 6.11 point 23):
>
> """ Assignment statements preceding posix special builtins persist in
> the shell environment after the builtin completes."""
>
> The above example should always print "a" but with "#local x" commented
> it prints "b". This is obviously wrong; the x variable is not even used.
>
> This can be reproduced on all versions of bash since at least bash-3.0
> (probably on bash-2 as well). I also checked Debian's dash as an
> alternative posix-compliant shell and it always prints "a" as expected.
For reference, ksh93, busybox ash and zsh (with setopt posixbuiltins)
print "a"
Re: Passing variables to and from custom programs
On Feb 6, 5:37 pm, djackn wrote:
> May I used the following in a bash script to pass variables to myIpExec?
>
> Result = myIpExec(${IPaddr1} ${IPaddr2} ${IPaddr3} ${IPaddr4})
>
> myIpExec is a c program that normally uses scanf to prompt the user
> for the IP addresses and returns 0 or 1.
> I plan to use the script to test the program for various inputs.
> --
> View this message in
> context:http://old.nabble.com/Passing-variables-to-and-from-custom-programs-t...
> Sent from the Gnu - Bash mailing list archive at Nabble.com.
It is more likely that this would work:
Result=$(echo "{IPaddr1} ${IPaddr2} ${IPaddr3} ${IPaddr4}" | myIpExec)
Note that there are no spaces around the equal sign.
Re: command not put into history if it starts with space
On Feb 5, 4:07 am, Paul Stansell wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i386 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' > -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include > -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 > -march=i686 -mtune=atom -fasynchronous-unwind-tables > uname output: Linux ram.opd.local 2.6.31.12-174.2.3.fc12.i686 #1 SMP > Mon Jan 18 20:22:46 UTC 2010 i686 athlon i386 GNU/Linux > Machine Type: i386-redhat-linux-gnu > > Bash Version: 4.0 > Patch Level: 35 > Release Status: release > > Description: > > 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. > > Repeat-By: > > Type any command prefixed by one or more spaces. Press return. Press > Ctrl-p or type "history | tail". Observe that last command starting > with space is not in present in the command history. > > Thanks, > > Paul Stansell >From the Bash man page: HISTCONTROL A colon-separated list of values controlling how commands are saved on the history list. If the list of values includes ignorespace, lines which begin with a space character are not saved in the history list.
Re: Bash sometimes cannot find aliases
On Jan 28, 2:55 am, Dan Zwell wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' > -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64 > -mtune=generic -O2 -pipe > uname output: Linux mordor 2.6.32-ARCH #1 SMP PREEMPT Mon Jan 18 > 23:30:46 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz > GenuineIntel GNU/Linux > Machine Type: x86_64-unknown-linux-gnu > > Bash Version: 4.1 > Patch Level: 2 > Release Status: release > > Description: > When I attempt to run an alias, Bash occasionally says the command is > not found. Re-running the command generally succeeds. This also occurs > with aliases that are named after existing programs. For example, > running "ls", which is aliased to "ls --color", occasionally results in > "ls" being run without the "--color" argument (the alias is bypassed). > > Repeat-By: > This problem seems to occur once every few hundred aliased commands I > run. It seems more frequent immediately after sourcing a .bashrc file. I > cannot reproduce it with a loop that repeatedly runs an aliased command. > > Is this a known issue? I may be able to help debug this (perhaps by > modifying my build to log state when a command is not found). > > Thanks > -Dan I can think of two ways to bypass an alias that will produce the behavior you describe. These are by design. Perhaps the issue you are experiencing is related or perhaps not. /tmp$ alias alias ls='ls --color=always' /tmp$ ls /tmp$ \ls /tmp$ command ls /tmp$ alias p=pwd /tmp$ p /tmp /tmp$ \p p: command not found /tmp$ command p p: command not found /tmp$ echo \\ > backslash /tmp$ . ./backslash /tmp$ p p: command not found /tmp$ p /tmp So perhaps the file you are sourcing has a stray backslash at the end.
Re: Sort: problem with option -f
On Jan 28, 8:43 am, Guido Milanese wrote: > I am facing a problem concerning SORT on a Linux Ubuntu 9.04 > distribution. > I noticed that the -f option seems not to work. This is an example: > DOG > CAT > zebra > dog > ZEBRA > mouse > > Running "sort" on the file I get: > CAT > dog > DOG > mouse > zebra > ZEBRA > > Running "sort -f " I get the same result. No problem of encoding, being > plane letters <127 -- to be sure I saved the list as 'test', and "file > test" says it's a pure ASCII text. Without the '-f' option, 'sort' used to > distinguish among lowercase / uppercase. > Is this a bug or a new behaviour of 'sort' ? > > Thanks! > guido > guido.milan...@unicatt.itwww.arsantiqua.org This has little or nothing to do with Bash. Try this: LANG=C sort
Re: variable assignment in string returning function
On Jan 27, 10:54 am, "Chris F.A. Johnson"
wrote:
> On Wed, 27 Jan 2010, Sharuzzaman Ahmat Raslan wrote:
> > I found the behaviour of the function below is a little bit odd. Appreciate
> > if someone can share his/her knowledge regarding the behaviour.
>
> > The output of the script will be:
>
> > sharuzza...@debian:~$ ./case1.sh
> > Nice behaviour,
>
> > Somehow, the backtick for foo() execute the function, echoing the correct
> > output, but fails to set the variable $gang to the correct value. Because of
> > that, the function bar() did not echoing anything because the variable $gang
> > is null.
>
> > I would expect that $gang is set with the correct value and function bar()
> > will work after that.
> ...
> > #startscript--
> > #!/bin/bash
>
> > # test case for variable assignment in string returning function
> > # case 1: function with echo
>
> > name="optimus"
>
> > foo () {
> > if [ "$name" = "optimus" ]
> > then
> > gang="good"
> > echo "Nice behaviour"
> > else
> > gang="bad"
> > echo "Naughty behaviour"
> > fi
> > }
>
> > bar () {
> > case "$gang" in
>
> > good)
> > echo "autobot"
> > ;;
>
> > bad)
> > echo "decepticon"
> > ;;
> > esac
> > }
>
> > behaviour=`foo`
> > group=`bar`
>
> > echo $behaviour,$group
> > #endscript
>
> name="optimus"
>
> foo () {
> if [ "$name" = "optimus" ]
> then
> gang="good"
> echo "Nice behaviour"
> return 0
> else
> gang="bad"
> echo "Naughty behaviour"
> return 1
> fi
>
> }
>
> bar () {
> case "$gang" in
>
> good)
> echo "autobot"
> return 0
> ;;
>
> bad)
> echo "decepticon"
> return 1
> ;;
> esac
>
> }
>
> behaviour=`foo` && gang=good || gang=bad
> group=`bar` && gang=good || gang=bad
>
> echo $behaviour,$group
>
> --
> Chris F.A. Johnson
> ===
> Author:
> Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
> Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Setting gang based on the return values of bar is redundant.
Re: Selecting out of an array
On Jan 25, 7:28 pm, Jon_R wrote:
> Hello List,
>
> I am new to shell scripting and programming in general, so please excuse my
> ignorance. :)
>
> I am trying to setup a menu for some videos that I have so that you can
> select one and it will play it using xine or mplayer. My first attempt was
> to assign each video a variable name and then I could select which video and
> then play it. This is not very efficient because I always have to assign a
> new variable to a new video.
>
> I am now trying to populate an array using the 'ls' command. I have attached
> the script below.
>
> This gives me this as output to the screen:
> 0: video1
> 1: video10
> 2: video11
> 3: video2
> 4: video3
> 5: video4
> 6: video5
> 7: video6
> 8: video7
> 9: video8
> 10: video9
> 1) video9
> #?
>
> I get the prompt waiting for me to make a selection "#?". I then have a
> 'printf' statement that should print out my selection using the index number
> but it is not working. When I choose '1' I get video9 even though it is
> index number 10.
>
> Why does it even print "1) video9" when it should be waiting for input from
> the user?
>
> http://old.nabble.com/file/p27316649/newsh2.shnewsh2.sh
>
> Thanks for any help,
>
> Jon
> --
> View this message in
> context:http://old.nabble.com/Selecting-out-of-an-array-tp27316649p27316649.html
> Sent from the Gnu - Bash mailing list archive at Nabble.com.
It's not necessary to print the array, select will do that for you.
The way you're using select makes it only have access to one value
which is the last one in the array because the "for index" loop leaves
index pointing to the last array element. Also, don't use ls like this
- it's eyes-only.
Try this (or something similar):
if [ $# -eq 0 ]; then
ARRAY=( quit /home/jonr/Download/videoDriver/video/* ) # file
globbing instead of ls
select ITEM in "${arr...@]}" ; do #
using @ as the subscript
if [[ $ITEM == "quit" ]]
then
break
fi
printf "%s\n" "$ITEM" # this
is where you'd process the selection
done
else
echo "Nothing to see here"
fi
The @ sign gives select access to the whole array.
Re: Problems when RANDOM without $ is used as an array index
On Jan 20, 7:28 am, Stephane CHAZELAS wrote: > 2010-01-12 22:07:31 -0500, Chet Ramey: > > > > > On 1/12/10 5:16 AM, Stephane CHAZELAS wrote: > > > 2010-01-11, 17:42(-05), Chet Ramey: > > Think of it as > > > x = $(( RANDOM%6+1 + RANDOM%6+1 )) > > y = dice[x] > > dice[RANDOM%6+1 + RANDOM%6+1] = y + 1 > > return y > > >>> [...] > > > >>> I would still consider that a bug. > > > >> OK. But everyone does it the same way. > > > > Except for pdksh, mksh, posh, perl, C. > > > The three shells in your list are all variants of the same base. It's > > like using three different releases of bash. The other two aren't > > shells. C is a reasonable comparison, but there are other differences > > in how the languages are parsed and executed. > > > > I think by "everyone", you mean "AT&T ksh" and "zsh" or do you > > > know any other shell or language that behaves like that? > > > I haven't done an extensive investigation. It's not really a significant > > issue. It's important enough that bash, ksh, and zsh agree. We don't > > need more incompatibilities between the major shells. > > [...] > > Hi Chet, > > Please note that that bug has now been fixed in > ksh93:http://mailman.research.att.com/pipermail/ast-developers/2010q1/00055... > so they don't agree anymore. > > -- > Stephane I wasn't able to access that link until I changed it to https https://mailman.research.att.com/pipermail/ast-developers/2010q1/000550.html
Re: possible bug on readline
On Jan 18, 11:01 am, Chet Ramey wrote:
> On 1/18/10 12:40 AM, Samus_ wrote:
>
> > hello, I had this on my shell: fgrep "$(nl_join " templates/
> > advertiser/campaign* and when tried to perform readline's glob-expand-
> > word I got some parse errors, I'm not sure if it is a bug or the
> > expected behaviour because the line isn't functional code however I'm
> > not sure if that should affect the expansion.
>
> This is the behavior of the completion function you have installed for
> "fgrep". Without any completions installed, bash-4.1 behaves as you
> would expect.
>
> > ps: bash at gnu.org rejected my email.
>
> That's not a valid email address.
>
> 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/
But it's not fgrep's completion function if there's nothing on the
command line but:
"$("
(including quotes).
Re: possible bug on readline
On Jan 17, 11:40 pm, Samus_ wrote:
> to reproduce simply try to glob-expand the following code: "$(" *
You can reproduce that without the asterisk.
I doubt that that's a bug in readline. The errors you're getting are
from tab-completion which is done in a
script. It's not handling the quotes properly when there's a command
substitution started.
When I try this, I get line numbers like 4505. If I cancel and do it
again, the line numbers of the errors increase.
Re: history position out of range
On Jan 14, 2:11 pm, Sergio Monteiro Basto wrote: > Hi, > How I delete history from entry 2 to entry 22 > > $ history -d 2:22 > bash: history: 2:22: history position out of range > > man history say: > > history -d offset > > where is define, the sintax of the offset? > > Thanks in advance, > -- > Sérgio M. B. > > smime.p7s > 4KViewDownload See noun definition 6: http://en.wiktionary.org/wiki/offset an offset is a distance, not a range. Also, see my previous answer for a snippet that will perform your delete by range for you. You could wrap it in a function.
Re: history position out of range
On Jan 13, 2:29 pm, Sérgio Monteiro Basto wrote:
> Hi,
> How I delete history from entry 2 to entry 22
>
> $ history -d 2:22
> bash: history: 2:22: history position out of range
>
> man history say:
>
> history -d offset
>
> where is define, the sintax of the offset?
>
> Thanks in advance,
> --
> Sérgio M. B.
I believe it only takes a single value rather than a range.
You can do this:
$ for i in {22..2}; do history -d $i; done
Note the reversal of the range.
Re: Problems when RANDOM without $ is used as an array index
On Jan 11, 3:53 pm, Stephane CHAZELAS wrote: > 2010-01-11, 15:59(-05), Chet Ramey: > [...]> Think of it as > > > x = $(( RANDOM%6+1 + RANDOM%6+1 )) > > y = dice[x] > > dice[RANDOM%6+1 + RANDOM%6+1] = y + 1 > > return y > > [...] > > I would still consider that a bug. > > I don't think anyone would expect x to be incremented by 2 in a[++x]++ > and it doesn't in any other language I know (except AT&T ksh and > zsh (under some circumstances)). > > -- > Stéphane It's definitely a gotcha.
Re: ERR trap inheritance in command substitution
On Jan 8, 11:50 am, Stefan Götz
wrote:
> Hi!
>
> It seems that in bash version 4.0.33(1)-release (i486-pc-linux-gnu) (from
> Ubuntu
> 9.04), ERR traps are not inherited by functions that are called via command
> substitution. I expected inheritance to apply in this case since the
> documentation of 'set -E' promises inheritance of the ERR trap for subshell
> contexts. The script below illustrates this behavior as the trap action
> err_handler() is not called.
>
> Is this behaviour intended? Even if so, I'd like to say that I would find ERR
> trap inheritance for command substitution extremely useful :-)
>
> Cheers,
> Stefan
>
> #!/bin/bash
>
> err_handler() {
> echo "THERE WAS AN ERROR"
>
> }
>
> set -E
> trap 'err_handler' ERR
>
> myfunc() {
> false # fails to cause an ERR trap
> true
>
> }
>
> FOO=$(myfunc)
> exit 0
>
> signature.asc
> < 1KViewDownload
Change your error handler to output to stderr:
err_handler() {
echo "THERE WAS AN ERROR" >&2
}
Re: Query regarding ${parameter:-word} usage
On Dec 23, 6:51 pm, Mun wrote:
> Hi,
>
> I am moving from ksh93 to bash and have a question regarding the usage
> of ${parameter:-word} parameter expansion.
>
> In ksh, I use ${*:-.} as an argument to commands. For example:
>
> function ll
> {
> ls --color -Flv ${*:-.}
> }
>
> This technique passes '.' as an arg to 'ls' if I didn't pass any args on
> the command line (as I'm sure you all already know). But this does not
> work with bash; nor have I been able to come up with a technique that
> accomplishes the same thing. My only workaround so far is to put an
> 'if' loop around the 'ls' that tests $# and takes the appropriate branch
> depending on the number of args (i.e., 0 or non-zero).
>
> Any suggestions would be welcomed. Thanks in advance.
>
> --
> Mun
"This does not work with Bash" - In what way? It works fine for me.
Re: want a M-. that ignores C-r
On Dec 18, 10:17 am, jida...@jidanni.org wrote: > Same question for years: > Want some way for M-. to get the last item, regardless of if we are here > via a C-r or not. I want some dumber-downed version of M-., however at > the same time I don't want to use that cshell ! stuff. I want something > I can bind to M-.. Thanks. Can you be more specific about what it is you're trying to do? If I press M-. I get the last item regardless of whether I've pressed C-r. That is the default behavior.
Re: compgen -f failing on directory containing single quote
On Dec 13, 8:17 am, Freddy Vulto wrote: > On 091213 05:13, DennisW wrote: > > > However, with quoting, these work: > > > compgen -f "a\'b/" > > compgen -f 'a\"b/' > > > or using a variable: > > > dir="a\'b/"; compgen -f $dir > > Both do not work at my machine? Are you sure you don't have a directory > `ab' besides `a\'b'? That's whap happened to me too... > It seems compgen is leaving out the quote out erroneously: > > $ mkdir a\'b > $ touch a\'b/c > $ mkdir ab > $ touch ab/e > $ compgen -f a\'b/ > ab/e # Should be a\'b/c > > Freddy Vultohttp://fvue.nl $ ls -ld a*b ls: cannot access a*b: No such file or directory $ mkdir a\'b $ touch a\'b/c $ compgen -f a\'b/ $ compgen -f "a\'b/" a\'b/c# correct $ mkdir ab $ touch ab/e $ compgen -f "a\'b/" a\'b/c# correct $ compgen -f a\'b/ a\'b/e# INcorrect $ echo $BASH_VERSION# Ubuntu 9.10 4.0.33(1)-release However I just tested it under Cygwin with Bash 3.2.49(23)-release and got these results similar to yours: $ ls -ld a*b ls: cannot access a*b: No such file or directory $ mkdir a\'b $ touch a\'b/c $ compgen -f a\'b/ $ compgen -f "a\'b/" $ mkdir ab $ touch ab/e $ compgen -f "a\'b/" a\'b/e# INcorrect $ compgen -f a\'b/ ab/e # INcorrect Here, the quotes didn't give the correct results, but gave different incorrect ones.
Re: compgen -f failing on directory containing single quote
On Dec 13, 4:07 am, Freddy Vulto wrote:
> `compgen -f' produces no output if the directory contains a single quote.
> I get the same result on both bash-3.2.39 and bash-4.0.35.
>
> Steps to reproduce the problem:
>
> $ mkdir a\'b
> $ touch a\'b/{c,d}
> $ compgen -f a\'b/
> $
>
> Expected output:
>
> a\'b/c
> a\'b/d
>
> Freddy Vultohttp://fvue.nl
Same behavior with a double quote.
However, with quoting, these work:
compgen -f "a\'b/"
compgen -f 'a\"b/'
or using a variable:
dir="a\'b/"; compgen -f $dir
Re: add a way to declare global variables
On Dec 12, 4:24 am, Bernd Eggink wrote:
> Am 12.12.2009 02:11, schrieb Matthew Woehlke:
>
> > konsolebox wrote:
> >> I hope the development team will also consider adding a way in bash to
> >> declare global variables inside a function perhaps either with an
> >> option in typeset or declare like -g (same as zsh) and/or a builtin
> >> function like global as similar to local.
>
> > I thought variables in functions were /always/ global unless declared
> > local?
>
> It's the other way round. Regarding typeset and declare, the man page
> says: " When used in a function, makes each name local, as with the
> local command. " So within a function, typeset, declare, and local are
> synonyms. Using 'local' outside a function is an error, so IMHO this
> command is completely redundant. It _would_ make some sense, however, if
> its counterpart 'global' existed, as it could help clarify the intended
> usage of the variable.
>
> Bernd
>
> --
> Bernd Egginkhttp://sudrala.de
$ vars () { var1=123; local var2=456; }
$ vars
$ echo "var1=$var1 "var2=$var2"
var1=123 var2=
How is that "the other way around"?
Re: Error on meta-{ filename expansion
On Dec 9, 10:05 am, Jeff Terrell wrote:
> (pasted this in from dead.bashbug when the mail failed.)
>
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -
> DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -
> DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -
> DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/
> lib -g -O2 -Wall
> uname output: Linux art 2.6.24-23-generic #1 SMP Mon Jan 26 00:13:11
> UTC 2009 i686 GNU/Linux
> Machine Type: i486-pc-linux-gnu
>
> Bash Version: 3.2
> Patch Level: 39
> Release Status: release
>
> Description:
> The meta-{ command should automatically expand filenames that match the
> current prefix into a {,,,} list. I found a test case for which this
> does not work correctly.
>
> Repeat-By:
> $ mkdir tmp; cd tmp
> $ cat | xargs touch # paste the following lines in; terminate with ^d
> app-controllers-account_reminders_controller_rb.html
> app-controllers-accounts_controller_rb.html
> app-controllers-account_settings_controller_rb.html
> app-controllers-application_rb.html
> app-controllers-backup_aging_controller_rb.html
> app-controllers-backup_verification_controller_rb.html
> app-controllers-controller_represents_rb.html
> app-controllers-dashboard_controller_rb.html
> app-controllers-domains_controller_rb.html
> app-controllers-file_spaces_controller_rb.html
> app-controllers-help_pages_controller_rb.html
> app-controllers-licenses_controller_rb.html
> app-controllers-logs_controller_rb.html
> app-controllers-nodes_controller_rb.html
> app-controllers-node_test_cases_controller_rb.html
> app-controllers-platforms_controller_rb.html
> app-controllers-preferences_controller_rb.html
> app-controllers-rubyamf_controller_rb.html
> app-controllers-sessions_controller_rb.html
> app-controllers-storage_visualizer_controller_rb.html
> app-controllers-support_controller_rb.html
> app-controllers-sweeps_controller_rb.html
> app-controllers-tsm_servers_controller_rb.html
> ^d
> $ rm # expands to a long list of filenames
> rm: cannot remove `app-controllers-account__controller_rb.html': No such
> file or directory
> $ rm # expands to: app-controllers-accounts_controller_rb.html
>
> Thanks,
> -Jeff T.
That was under Ubuntu 9.10 for Bash 4.0.33(1)-release, by the way.
It also works for me under cygwin in Bash 3.2.49(23)-release.
One thing I noticed is that the error message for rm has two
underscores in a row. Is that just a typo (or "pasto")?
Re: Error on meta-{ filename expansion
On Dec 9, 10:05 am, Jeff Terrell wrote:
> (pasted this in from dead.bashbug when the mail failed.)
>
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -
> DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -
> DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -
> DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/
> lib -g -O2 -Wall
> uname output: Linux art 2.6.24-23-generic #1 SMP Mon Jan 26 00:13:11
> UTC 2009 i686 GNU/Linux
> Machine Type: i486-pc-linux-gnu
>
> Bash Version: 3.2
> Patch Level: 39
> Release Status: release
>
> Description:
> The meta-{ command should automatically expand filenames that match the
> current prefix into a {,,,} list. I found a test case for which this
> does not work correctly.
>
> Repeat-By:
> $ mkdir tmp; cd tmp
> $ cat | xargs touch # paste the following lines in; terminate with ^d
> app-controllers-account_reminders_controller_rb.html
> app-controllers-accounts_controller_rb.html
> app-controllers-account_settings_controller_rb.html
> app-controllers-application_rb.html
> app-controllers-backup_aging_controller_rb.html
> app-controllers-backup_verification_controller_rb.html
> app-controllers-controller_represents_rb.html
> app-controllers-dashboard_controller_rb.html
> app-controllers-domains_controller_rb.html
> app-controllers-file_spaces_controller_rb.html
> app-controllers-help_pages_controller_rb.html
> app-controllers-licenses_controller_rb.html
> app-controllers-logs_controller_rb.html
> app-controllers-nodes_controller_rb.html
> app-controllers-node_test_cases_controller_rb.html
> app-controllers-platforms_controller_rb.html
> app-controllers-preferences_controller_rb.html
> app-controllers-rubyamf_controller_rb.html
> app-controllers-sessions_controller_rb.html
> app-controllers-storage_visualizer_controller_rb.html
> app-controllers-support_controller_rb.html
> app-controllers-sweeps_controller_rb.html
> app-controllers-tsm_servers_controller_rb.html
> ^d
> $ rm # expands to a long list of filenames
> rm: cannot remove `app-controllers-account__controller_rb.html': No such
> file or directory
> $ rm # expands to: app-controllers-accounts_controller_rb.html
>
> Thanks,
> -Jeff T.
Works as expected in Bash 4.0.33(1)-release.
Re: bash is not capable of comparing of strings and real numbers
On Dec 8, 7:11 am, Greg Wooledge wrote: > On Mon, Dec 07, 2009 at 05:08:02PM -0800, DennisW wrote: > > Since printf understands floats (or acts like it does), you can use it > > plus a little care and luck to do float comparisons in Bash: > > [...] > > $ printf -v a "%08.2f" $a > > $ printf -v b "%08.2f" $b > > $ [[ $a < $b ]] && echo true || echo false > > false # CORRECT > > echo "$a $b" > > 00147.10 00023.00 > > While this is certainly clever, it requires some knowledge of the > possible range of values being compared, so that one can construct a > suitable printf format specifier. Any unexpectedly large or small > input would break it. > > Real floating-point comparisons require the services of an external > program (such as bc or awk) since bash has no built-in support for it. > (Or a loadable bash builtin, but very few people use those.) That's where the "care and luck" come in. With some convoluted gyrations, code could scale the width and precision factors. It's not the most desirable way to do it, but as you say, it's "clever". So how come ksh has float and Bash doesn't?
Re: bash is not capable of comparing of strings and real numbers
On Dec 7, 4:22 pm, pk wrote: > phani krishna jampala wrote: > > bash is not capable of comparing of strings ( imean interms of lessthan or > > greater than etc) > > It is, if you use [[ ]] > > a="abcd" > b="bcde" > if [[ "$b" > "$a" ]]; then > echo "$b is greater than $a" > fi > > > and real numbers ( the float values). > > True, but I can't really speak as to whether this is planned or not (I think > it isn't, but of course I might be wrong). Since printf understands floats (or acts like it does), you can use it plus a little care and luck to do float comparisons in Bash: $ a=.3 $ b=0.2 $ [[ $a < $b ]] && echo true || echo false true # WRONG $ printf -v a "%0.2f" $a $ printf -v b "%0.2f" $b $ [[ $a < $b ]] && echo true || echo false false# CORRECT echo "$a $b" 0.30 0.20 $ a=147.1 $ b=23 $ [[ $a < $b ]] && echo true || echo false true # WRONG $ printf -v a "%08.2f" $a $ printf -v b "%08.2f" $b $ [[ $a < $b ]] && echo true || echo false false# CORRECT echo "$a $b" 00147.10 00023.00
Re: Fullscreen & unchecking show menubar.
On Dec 6, 9:39 pm, Rodney Varney III wrote: > From: rodne...@gmail.com > To: bug-b...@gnu.org,b...@packages.debian.org > Subject: Full screen and unchecking show menubar > > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib > -g -O2 -Wall > uname output: Linux pauseland 2.6.28-17-generic #58-Ubuntu SMP Tue Dec 1 > 21:27:25 UTC 2009 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 3.2 > Patch Level: 48 > Release Status: release > > Description: > I've noticed that if you full screen bash in a graphical interface, > and > click "view" then uncheck menubar, you cannot escape the terminal unless > you type > in exit. Kinda annoying when you are doing something important in bash. > > Repeat-By: > View, fullscreen, view, uncheck show menubar > > Fix: > I would suggest instead of the menubar dissapearing, you could have it > pop out whenever the mouse pointer touches the top of the screen. That has absolutely nothing at all to do with Bash.
Re: output redirection with process substitution asynchronous?
On Dec 7, 10:25 am, Marc Herbert wrote:
> Marc Herbert wrote:
> > What is wrong with the following:
>
> > prefix_with_date ()
> > {
> > while read; do
> > printf '%s: %s\n' "$(date)" "$REPLY";
> > done
> > }
>
> > seq 4 | prefix_with_date
> > ls | prefix_with_date
>
> Sorry I missed the fact that you want to run your commands in the current
> shell.
>
> There are no real coroutines in shell. The current shell process does
> not know how to schedule two pieces of code. So each time two
> pieces of code communicate through a pipe they have to be run in two
> *concurrent* processes (typically: subshells). The producer and
> consumer of a pipe must run independently of each other. Whether you
> are using process substitution or the more usual and portable pipe "|"
> does not matter here: you need concurrency.
>
> So at least one of: 1. your prefixer code, 2. your unknown command
> has to run in a independent process, "asynchronous" with the current
> shell.
>
> Since you absolutely want your unknown commands to run in the current
> shell, then it is your "prefixing" code that has to run in a
> concurrent process.
>
> Now I do not really see any other way to avoid the ugliness of
> concurrently printing on stdout than to "wait" for your concurrent
> prefixer to complete, more or less like you did.
>
> A variant is to ask socat to handle the cleanup actions for you like
> this:
>
> prefix_with_date()
> {
> local P=/tmp/dataorig.$$
> socat -u PIPE:${P} SYSTEM:'while read; do echo "$(date):\\ $REPLY";
> done' &
> socatPID=$!
> until [ -e ${P} ]; do sleep 1; done
> $@ > ${P}
> wait $socatPID
>
> }
>
> prefix_with_date seq 5
Would you care to comment on the coproc command in Bash 4?
Re: output redirection with process substitution asynchronous?
On Dec 5, 3:14 am, pjodrr wrote:
> Hello,
>
> On Dec 4, 8:18 pm, DennisW wrote:
>
> > It works for me. Does it not for you? If you're asking why not do it,
> > then the answer is "why call an external program unnecessarily?".
>
> > Sorry, by the way, I missed what you were doing with the file
> > descriptor on my first read. What is it that you're trying to
> > accomplish? Are you doing this only to number the lines or is either
> > seq or the while loop a stand-in for something else?
>
> the seq was only an example for demonstration.
> here is another example that shows what I mean:
>
> $ exec 3> >(while read line; do echo "tag: $line"; done)
> $ seq 4 >&3
> tag: 1
> tag: 2
> tag: 3
> tag: 4
>
> $ exec 3> >(while read line; do echo "$(date): $line"; done)
> $ seq 4 >&3
> $ Sat Dec 5 10:11:25 CET 2009: 1
> Sat Dec 5 10:11:25 CET 2009: 2
> Sat Dec 5 10:11:25 CET 2009: 3
> Sat Dec 5 10:11:25 CET 2009: 4
>
> while in the first example the prompt returns after the
> command completes, the prompt returns immediately
> in the second example.
>
> thanks for your attention,
>
> Peter
Your example here:
$ exec 3> >(while read line; do echo "tag: $line"; done)
$ seq 4 >&3
just executes too quickly to exhibit this behavior. Try this and it
will do it, too:
$ exec 3> >(while read line; do for i in {1..1}; do :; done; echo
'.'; done)
$ seq 4 >&3
I think the thing to remember is that doing this is like running
something in the background with "&". So, yes, it's going to be
asynchronous.
Re: functions can be created with dotted name but not removed
On Dec 4, 9:25 am, "Michael O'Donnell" wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
> -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2
> -Wall
> uname output: Linux e521 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009
> i686 GNU/Linux
> Machine Type: i486-pc-linux-gnu
>
> Bash Version: 4.0
> Patch Level: 28
> Release Status: release
>
> Description:
>
> A bash function with a dot in its name can be created and used with no
> problems but cannot be removed - the "unset" command chokes on the name.
>
> Repeat-By:
>
> This sequence yields the expected results:
>
> function f() { echo $FUNCNAME ; }
> f
> unset f
>
> ...while this sequence fails during the unset phase with the complaint
> that the name is not a valid identifier:
>
> function f.dot() { echo $FUNCNAME ; }
> f.dot
> unset f.dot
I can confirm that this behavior is also present in 3.2.49(23)-release
and 4.0.33(1)-release.
Re: output redirection with process substitution asynchronous?
On Dec 4, 12:58 pm, pk wrote: > pjodrr wrote: > > Hello, > > > how can I prefix every line of output of some command with a > > timestamp? I thought like this: > > > $ exec 3> >(while read line; do echo "$(date): $line"; done) > > $ seq 4 >&3 > > Friday, December 4, 2009 4:20:29 PM MET: 1 > > $ Friday, December 4, 2009 4:20:29 PM MET: 2 > > Friday, December 4, 2009 4:20:29 PM MET: 3 > > Friday, December 4, 2009 4:20:29 PM MET: 4 > > > please note that the prompt ($) returns before the command completes. > > Why is the > > process substitution asynchronous? > > Does anybody know of a better way to accomplish this? > > What's wrong with > > seq 4 | while read line; do echo "$(date): $line"; done It works for me. Does it not for you? If you're asking why not do it, then the answer is "why call an external program unnecessarily?". Sorry, by the way, I missed what you were doing with the file descriptor on my first read. What is it that you're trying to accomplish? Are you doing this only to number the lines or is either seq or the while loop a stand-in for something else?
Re: output redirection with process substitution asynchronous?
On Dec 4, 9:28 am, pjodrr wrote: > Hello, > > how can I prefix every line of output of some command with a > timestamp? I thought like this: > > $ exec 3> >(while read line; do echo "$(date): $line"; done) > $ seq 4 >&3 > Friday, December 4, 2009 4:20:29 PM MET: 1 > $ Friday, December 4, 2009 4:20:29 PM MET: 2 > Friday, December 4, 2009 4:20:29 PM MET: 3 > Friday, December 4, 2009 4:20:29 PM MET: 4 > > please note that the prompt ($) returns before the command completes. > Why is the > process substitution asynchronous? > Does anybody know of a better way to accomplish this? > > Thanks, > > Peter This should be in gnu.bash rather than gnu.bash.bug Would this work for you? while read line; do echo "$(date): $line $((num++))"; done
Re: Array parameter expansion with non-space-IFS on bash-3/4
On Nov 27, 3:47 pm, Freddy Vulto wrote:
> I noticed different behaviour between bash-3 and bash-4 when
> performing parameter expansion on an array with IFS set to a non-space
> value. For example, on bash-3.2.39, I get:
>
> $ bash -c 'IFS=:; printf "<%s>\n" "${@/q}"' x a b
>
>
> Whereas on bash-4.0.33, I get:
>
> $ bash -c 'IFS=:; printf "<%s>\n" "${@/q}"' x a b
>
>
>
> Bash-4 seems to give the desired result (leave the array intact), but
> it's a bug on bash-3?
>
> Regards,
>
> Freddy Vultohttp://fvue.nl
It seems to be a combination of IFS and pattern substitution. There's
another difference shown below with an intact IFS, but referring to a
string as an array.
Using this script:
#!/bin/bash
v=(a b c)
w="d e f"
printf "<%s>\n" "$...@]/q}"
IFS=X
printf "<%s>\n" "$...@]/q}"
In Bash 4.0.33(1)-release I get:
In Bash 3.2.49(23)-release I get:
Other combinations of array vs. string, changing IFS or not, and/or
not using pattern substitution produce the same results in the two
versions.
Dennis
sysadmins: visit serverfault.com
Re: PROMPT_DIRTRIM skips depth n-1 when ~ is n
On Nov 28, 5:25 am, "dennis" wrote: > Configuration Information [Automatically generated, do not change]:Machine: > i486OS: linux-gnuCompiler: gccCompilation CFLAGS: -DPROGRAM='bash' > -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='lin$uname output: Linux emperor > 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:2$Machine Type: > i486-pc-linux-gnu > Bash Version: 4.0Patch Level: 33Release Status: release > Description: > If you are in a directory below ~ and you set PROMPT_DIRTRIM to the > depthminus 2 it includes the depth minus 1 directory in the prompt as > well. > Repeat-By: > $ mkdir -p /tmp/seven/six/five/four/three/two/one$ cd > /tmp/seven/six/five/four/three/two/one$ PS1="\w$ > "/tmp/seven/six/five/four/three/two/one$ > PROMPT_DIRTRIM=0/tmp/seven/six/five/four/three/two/one$ > PROMPT_DIRTRIM=1.../one$ PROMPT_DIRTRIM=2.../two/one$ > PROMPT_DIRTRIM=3.../three/two/one$ PROMPT_DIRTRIM=4.../four/three/two/one$ > PROMPT_DIRTRIM=5.../five/four/three/two/one$ > PROMPT_DIRTRIM=6.../six/five/four/three/two/one$ > PROMPT_DIRTRIM=7.../seven/six/five/four/three/two/one$ > PROMPT_DIRTRIM=8/tmp/seven/six/five/four/three/two/one$ cd ~~$ mkdir -p > ~/seven/six/five/four/three/two/one~$ cd > ~/seven/six/five/four/three/two/one~/seven/six/five/four/three/two/one$ > PROMPT_DIRTRIM=0~/seven/six/five/four/three/two/one$ > PROMPT_DIRTRIM=1~/.../one$ PROMPT_DIRTRIM=2~/.../two/one$ > PROMPT_DIRTRIM=3~/.../three/two/one$ > PROMPT_DIRTRIM=4~/.../four/three/two/one$ > PROMPT_DIRTRIM=5~/.../five/four/three/two/one$ > PROMPT_DIRTRIM=6~/seven/six/five/four/three/two/one$ > > Repeated here without the prompts: > mkdir -p /tmp/seven/six/five/four/three/two/onecd > /tmp/seven/six/five/four/three/two/onePS1="\w$ > "PROMPT_DIRTRIM=0PROMPT_DIRTRIM=1PROMPT_DIRTRIM=2PROMPT_DIRTRIM=3PROMPT_DIR T > RIM=4PROMPT_DIRTRIM=5PROMPT_DIRTRIM=6PROMPT_DIRTRIM=7PROMPT_DIRTRIM=8cd > ~mkdir -p ~/seven/six/five/four/three/two/onecd > ~/seven/six/five/four/three/two/onePROMPT_DIRTRIM=0PROMPT_DIRTRIM=1PROMPT_D I > RTRIM=2PROMPT_DIRTRIM=3PROMPT_DIRTRIM=4PROMPT_DIRTRIM=5PROMPT_DIRTRIM=6 Once again, something - probably Linux vs. Windows line endings - screwed up my post. Here it is straightened out. Hopefully. Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' - DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' - DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' - DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/ lib -g -O2 -Wall uname output: Linux emperor 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 4.0 Patch Level: 33 Release Status: release Description: If you are in a directory below ~ and you set PROMPT_DIRTRIM to the depth minus 2 it includes the depth minus 1 directory in the prompt as well. Repeat-By: $ mkdir -p /tmp/seven/six/five/four/three/two/one $ cd /tmp/seven/six/five/four/three/two/one $ PS1="\w$ " /tmp/seven/six/five/four/three/two/one$ PROMPT_DIRTRIM=0 /tmp/seven/six/five/four/three/two/one$ PROMPT_DIRTRIM=1 .../one$ PROMPT_DIRTRIM=2 .../two/one$ PROMPT_DIRTRIM=3 .../three/two/one$ PROMPT_DIRTRIM=4 .../four/three/two/one$ PROMPT_DIRTRIM=5 .../five/four/three/two/one$ PROMPT_DIRTRIM=6 .../six/five/four/three/two/one$ PROMPT_DIRTRIM=7 .../seven/six/five/four/three/two/one$ PROMPT_DIRTRIM=8 /tmp/seven/six/five/four/three/two/one$ cd ~ ~$ mkdir -p ~/seven/six/five/four/three/two/one ~$ cd ~/seven/six/five/four/three/two/one ~/seven/six/five/four/three/two/one$ PROMPT_DIRTRIM=0 ~/seven/six/five/four/three/two/one$ PROMPT_DIRTRIM=1 ~/.../one$ PROMPT_DIRTRIM=2 ~/.../two/one$ PROMPT_DIRTRIM=3 ~/.../three/two/one$ PROMPT_DIRTRIM=4 ~/.../four/three/two/one$ PROMPT_DIRTRIM=5 ~/.../five/four/three/two/one$ PROMPT_DIRTRIM=6 ~/seven/six/five/four/three/two/one$ Without the prompts: mkdir -p /tmp/seven/six/five/four/three/two/one cd /tmp/seven/six/five/four/three/two/one PS1="\w$ " PROMPT_DIRTRIM=0 PROMPT_DIRTRIM=1 PROMPT_DIRTRIM=2 PROMPT_DIRTRIM=3 PROMPT_DIRTRIM=4 PROMPT_DIRTRIM=5 PROMPT_DIRTRIM=6 PROMPT_DIRTRIM=7 PROMPT_DIRTRIM=8 cd ~ mkdir -p ~/seven/six/five/four/three/two/one cd ~/seven/six/five/four/three/two/one PROMPT_DIRTRIM=0 PROMPT_DIRTRIM=1 PROMPT_DIRTRIM=2 PROMPT_DIRTRIM=3 PROMPT_DIRTRIM=4 PROMPT_DIRTRIM=5 PROMPT_DIRTRIM=6
Re: Use of pipe in $(< filename | program) returns null
On Nov 28, 4:46 am, Andreas Schwab wrote: > Bernd Eggink writes: > > Am 28.11.2009 06:35, schrieb r...@saturn.syslang.net: > > >> Description: > >> use of $(< filename | program) does not work. It either should or > >> it should be properly documented. > >> The problem also happens on bash4. > > >> Repeat-By: > > >> qq=$(< /etc/passwd | grep sys) > >> echo $qq > >> # result is null > > >> Fix: > >> Either fix the docs to tell people that a pipe is not allowed or > >> fix the code to allow it. > > > The problem is not the pipe but the fact that ' > command which does nothing. If you want 'program' to read from 'file', use > > program > Or even $(< /etc/passwd grep sys). > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." Or even $(grep sys /etc/passwd)
Re: <( error
On Nov 28, 8:44 am, Jan Schampera wrote:
> 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)
Works for me.
Neither you nor Antonio say what version of Bash or the OS.
I don't get an error and the output is correct.
I tried it in Bash 4.0.33(1)-release under Ubuntu 9.10 (using hd) and
Bash 3.2.49(23)-release under Cygwin 1.7.0 (using hexdump -C).
Re: Inconsistent results when history -s is used within PROMPT_COMMAND
Wow, that got really mangled somewhere! Here's the main part of the
test script again. Hopefully it'll come through OK this time.
histt() {
local space=''
space="${1:+ }" # set space to a space of there's a $1
local hist
local comment
hist=$(history 1)
hist="${hist# *[0-9]* }"
echo "before"
history 3
comment="some comment"
history -s "$space$hist # $comment"
echo "after"
history 3
PROMPT_COMMAND=$previous_prompt_command # put things back like you
found them
unset previous_prompt_command
unset histt
}
previous_prompt_command=$PROMPT_COMMAND
PROMPT_COMMAND="histt $1" # set up and run it
