Re: how to pass arguments with space inside?
The reason why I don't use "$@" is that the arguments to the bash script is
not completely those for the executable. Some of them are just arguments
only to the bash script. So actually the script is like
[code]
#!/bin/bash
DEBUGGER=""
ARG_OPTS=""
while [[ -n "$1" ]];
case $1 in
--run)
make clean
make -j -k || exit 1
DEBUGGER=""
;;
--gdb)
make clean
make -j -k DEBUG=yes || exit 1
DEBUGGER="gdb --args"
;;
*)
ARG_OPTS="${ARG_OPTS} $1"
;;
esac
shift
done
${DEBUGGER} my_executable ${ARG_OPTS}
[/code]
Chris F.A. Johnson-3 wrote:
>
> On Thu, 9 Apr 2009, lehe wrote:
>
>> Sorry. I won't top post again.
>
>You just did!
>
>> I tried your way but ARG_OPTS only accept the first argument and ignore
>> the
>> rest.
>
> ARG_OPTS=( "$@" )
>
> All the arguments are now in the array ARG_OPTS:
>
> printf "%s\n" "${arg_op...@]}"
>
>> Mike Frysinger wrote:
>>>
>>> On Thursday 09 April 2009 17:47:59 lehe wrote:
Thanks Mike.
>>>
>>> please do not top post
>>>
Mike Frysinger wrote:
> On Thursday 09 April 2009 16:46:27 lehe wrote:
>> I was wondering how to pass arguments with space inside. For example,
my
>> bash script looks like:
>>
>> #!/bin/bash
>> ARG_OPTS=""
>> while [[ -n "$1" ]];
>> ARG_OPTS="${ARG_OPTS} $1"
>> shift
>> done
>>
>> If I pass an argument like "--options='-t 0 -v 0'", then it would be
>> splitted by the spaces inside, ie "--options='-t", "0", "-v" and "0".
>>
>> How can I achieve what I wish?
>
> use arrays
>
> $ f=( a "b c" d)
> $ printf '%s\n' "$...@]}"
> a
> b c
> d
Could you explain it a little? I don't quite get it. How to apply this
to
argument parsing?
>>>
>>> instead of gathering stuff into the variable ARG_OPTS, declare it as a
>>> variable and gather it there:
>>> declare -a ARG_OPTS
>>> while [[ -n $1 ]] ; do
>>> arg_opts[${#arg_op...@]}]="$1"
>>> shift
>>> done
>>>
>>> then use it like i showed and the argument grouping will be preserved:
>>> "${arg_op...@]}"
>>>
>>> i imagine there are plenty of bash array howtos out there if you google
>>> -mike
>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/how-to-pass-arguments-with-space-inside--tp22978918p22981193.html
>> Sent from the Gnu - Bash mailing list archive at Nabble.com.
>>
>>
>>
>
> --
> Chris F.A. Johnson, webmaster
> = Do not reply to the From: address; use Reply-To:
> Author:
> Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
>
>
>
>
--
View this message in context:
http://www.nabble.com/how-to-pass-arguments-with-space-inside--tp22978918p22984063.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: how to pass arguments with space inside?
2009-04-09, 23:18(+02), Mart Frauenlob: [...] > I wonder where's the bug report? > You seem to miss that the support place for bash is 'gnu.bash' not > 'gnu.bash.bug'. [...] Interesting, I can see that Google groups has a gnu.bash newsgroup with messages that date back as far as 1999 newsgroup. I've never seen that newsgroup on usenet until I checked this morning and indeed one of the news servers I use (news.motzarella.org) has it (not aioe.org though) That newsgroup is not listed in http://ftp.isc.org/pub/usenet/control/gnu/ AFAICT its creation has not been announced on gnu.bash.bug which as far as I can tell has been used for discussing bash for at least a decade (though at times, it was only available via the email interface) gnu.bash is not referenced on bash's home page either (AFAICT) Where does it come from? What makes you say it is "the support place for bash"? -- Stéphane
Re: how to pass arguments with space inside?
On Fri, Apr 10, 2009 at 12:02:56AM -0700, lehe wrote:
> The reason why I don't use "$@" is that the arguments to the bash script is
> not completely those for the executable. Some of them are just arguments
> only to the bash script. So actually the script is like
So you need to build up an *array* of your parameters, not a string.
What you are trying to do does not, and cannot, work.
> [code]
> #!/bin/bash
> ...
> ${DEBUGGER} my_executable ${ARG_OPTS}
> [/code]
You have built up a string. There is no way to delimit individual
parameters inside a string other than whitespace, and when you need
whitespace *inside* one of those parameters, you're stuck. You need
an array instead, as others have already told you.
[code]
#!/bin/bash
...
$DEBUGGER my_executable "${my_arr...@]}"
[/code]
See also:
http://mywiki.wooledge.org/BashFAQ/050
"I'm trying to put a command in a variable, but the complex cases
always fail!"
http://mywiki.wooledge.org/BashFAQ/005
"How can I use array variables?"
Re: how to pass arguments with space inside?
Greg Wooledge eeg.ccf.org> writes:
>
> On Fri, Apr 10, 2009 at 12:02:56AM -0700, lehe wrote:
> > The reason why I don't use "$@" is that the arguments to the bash script is
> > not completely those for the executable. Some of them are just arguments
> > only to the bash script. So actually the script is like
>
> So you need to build up an *array* of your parameters, not a string.
> What you are trying to do does not, and cannot, work.
> You have built up a string. There is no way to delimit individual
> parameters inside a string other than whitespace, and when you need
> whitespace *inside* one of those parameters, you're stuck.
Not true, if you are careful and use eval. For example, something like the
following (lightly tested here, but based roughly on how autoconf does it in
configure scripts):
set 'two spaces' '*' "a'b'c'd"
args=
for arg
do
case $arg in
*\'*) arg=${arg//\'/"'\\''"} ;;
esac
args+=" '$arg'"
done
eval for arg in "$args" \; do echo \"\$arg\"\; done
And if you don't want to rely on the bash-specific ${name//pattern/repl} or +=,
you can rewrite those with something more portable to other shells.
--
Eric Blake
bash spell check
I am producing a program in bash which analyses a mailbox (.mbx) file. One of the outputs which i want it to be able to complete is to count how many times specified words appear in the file, however they are spelt. i.e spelling mistakes or other symbols used to replace letter, for e.g @ or 4 instead of A. I have originally done it to take in account different sysmbols etc although it does not account for spelling mistakes and wondered if there was a more efficient way in which it could be done? -- View this message in context: http://www.nabble.com/bash-spell-check-tp22972678p22972678.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
(set -u -e; trap true EXIT; echo $bad) exits 0
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 pzlaptop 2.6.22-gg15-generic #1 SMP Fri Sep 26 12:50:35 EST 2008 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 25 Release Status: release Description: The following command $ (set -u -e; trap true EXIT; echo $bad;) && echo OK displays bash: bad: unbound variable OK I'd think it should exits with a non-zero error code and not display OK. This is exacly what happens if you remove -e. I'm not sure whether this is of any use, but in the outputs below, we have '++ true' in the first case, and '+ true' in the other. $ (set -x -u -e; trap true EXIT; echo $bad;) + trap true EXIT bash: bad: unbound variable ++ true $ (set -x -u; trap true EXIT; echo $bad;) + trap true EXIT bash: bad: unbound variable + true Repeat-By: Execute the above command.
possible bash 4.0.10 bug: command substitution in PROMPT_COMMAND
Hi, I upgraded to bash 4.0.10 and my PS1 prompt is no longer displaying
anything at all. Here is a contrived .bashrc:
.bashrc:
BEGIN
f()
{
$(:)
PS1='$ '
}
PROMPT_COMMAND=f
END
However, it works if I take the command substitution sequence `$(...)'
out. Things get ever weirder if I try changing it on the command line:
-bash-4.0$ f() { PS1='$ '; echo foo; }; PROMPT_COMMAND=f
foo
$
This works as expected, but if I use a command substitution this time:
-bash-4.0$ f() { PS1='$ '; echo foo; $(:); }; PROMPT_COMMAND=f
foo
-bash-4.0$
My prompt didn't change. In fact, setting PS1 after this point in the
shell doesn't work at all until you 'unset PROMPT_COMMAND', at which
point PS1 will finally take on the value assigned by the PROMPT_COMMAND.
Further, if I put the command substitution inside a subshell, it does
work:
-bash-4.0$ f() { PS1='$ '; echo foo; ($(:)); }; PROMPT_COMMAND=f
foo
$
I have not tried the newer patch levels above 4.0.10, so sorry if this
has already been fixed, but I looked up to 4.0.15 briefly and did not
notice this address being addressed directly.
Specifically, I use this output of a command in my prompt (sorry to
offend anyone who finds that ridiculous), so it would be nice to have
the old functionality back if possible.
Thanks!
Re: how to pass arguments with space inside?
lehe wrote:
Hi,
I was wondering how to pass arguments with space inside. For example, my
bash script looks like:
#!/bin/bash
ARG_OPTS=""
while [[ -n "$1" ]];
ARG_OPTS="${ARG_OPTS} $1"
shift
done
If I pass an argument like "--options='-t 0 -v 0'", then it would be
splitted by the spaces inside, ie "--options='-t", "0", "-v" and "0".
How can I achieve what I wish?
Thanks and regards!
I wonder where's the bug report?
You seem to miss that the support place for bash is 'gnu.bash' not
'gnu.bash.bug'.
btw. check builtin 'eval'.
Greets
Mart
Re: how to pass arguments with space inside?
Stephane CHAZELAS wrote: 2009-04-09, 23:18(+02), Mart Frauenlob: [...] I wonder where's the bug report? You seem to miss that the support place for bash is 'gnu.bash' not 'gnu.bash.bug'. [...] Interesting, I can see that Google groups has a gnu.bash newsgroup with messages that date back as far as 1999 newsgroup. I've never seen that newsgroup on usenet until I checked this morning and indeed one of the news servers I use (news.motzarella.org) has it (not aioe.org though) That newsgroup is not listed in http://ftp.isc.org/pub/usenet/control/gnu/ AFAICT its creation has not been announced on gnu.bash.bug which as far as I can tell has been used for discussing bash for at least a decade (though at times, it was only available via the email interface) gnu.bash is not referenced on bash's home page either (AFAICT) Where does it come from? What makes you say it is "the support place for bash"? Oh! I'm sorry then... I came in here like this: search for 'bash' in my news client. gnu.bash.bug and gnu.bash showed up. Seemed obvious to me, that gnu.bash is for asking questions and gnu.bash.bug is for filing bug reports, and similar... Wrong assumption How should I see, that gnu.bash is not 'official'? Didn't notice, that the web page doesn't list gnu.bash. Interesting anyways :) Sorry again, didn't want to be mean greets Mart
UDP client programming
My script sends a UDP query to a server and gets a response datagram. All
packets are character strings and I have had trouble reading the response.
A method that I have found to work is to arrange for the response packet to
have a unique terminating character ('\0') and to pipe the response into a
trivial gawk script with RS="\0". Simpler methods such as using read or cat
fail. For read, "read -n1" will read one character but "read -nx", x!=1
just hangs. Piping the response into cat reads the response but the
pipeline does not terminate so my script cannot continue. I would like to
know if there are tricks and tips for using sockets more effectively in
bash. My search on the topic often simply advises users to keep away from
bash networking.
HM
Re: possible bash 4.0.10 bug: command substitution in PROMPT_COMMAND
Jared Yanovich wrote: Hi, I upgraded to bash 4.0.10 and my PS1 prompt is no longer displaying anything at all. I think this was addressed in a recent patch. Try upgrading to the most recent version. - Ian Kelling
Re: possible bash 4.0.10 bug: command substitution in PROMPT_COMMAND
On Thu, Apr 09, 2009 at 05:12:13PM -0400, Jared Yanovich wrote: > Specifically, I use this output of a command in my prompt (sorry to > offend anyone who finds that ridiculous), so it would be nice to have > the old functionality back if possible. You can do: PS1='$(your command) other stuff here' The command substitution will be performed every time the prompt is displayed.
Re: UDP client programming
On Friday 10 April 2009 08:06:17 Henri Moreau wrote:
> My script sends a UDP query to a server and gets a response datagram. All
> packets are character strings and I have had trouble reading the response.
> A method that I have found to work is to arrange for the response packet to
> have a unique terminating character ('\0') and to pipe the response into a
> trivial gawk script with RS="\0". Simpler methods such as using read or
> cat fail. For read, "read -n1" will read one character but "read -nx",
> x!=1 just hangs. Piping the response into cat reads the response but the
> pipeline does not terminate so my script cannot continue. I would like to
> know if there are tricks and tips for using sockets more effectively in
> bash. My search on the topic often simply advises users to keep away from
> bash networking.
showing example code people can run goes a lng way ...
-mike
signature.asc
Description: This is a digitally signed message part.
Re: (set -u -e; trap true EXIT; echo $bad) exits 0
Even within the EXIT trap, the -u error exit status disappears when -e is used (?): $ (set -u; trap 'echo $?' EXIT; echo $bad) bash: bad: unbound variable 1 $ (set -eu; trap 'echo $?' EXIT; echo $bad) bash: bad: unbound variable 0 Freddy Vulto http://fvue.nl
Re: possible bash 4.0.10 bug: command substitution in PROMPT_COMMAND
Jared Yanovich wrote:
> Hi, I upgraded to bash 4.0.10 and my PS1 prompt is no longer displaying
> anything at all. Here is a contrived .bashrc:
>
> .bashrc:
> BEGIN
> f()
> {
> $(:)
> PS1='$ '
> }
> PROMPT_COMMAND=f
> END
>
> However, it works if I take the command substitution sequence `$(...)'
> out.
I cannot reproduce this using bash-4.0.10 or bash-4.0.17 on Mac OS X,
Ubuntu, RHEL 4, or FreeBSD.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: possible bash 4.0.10 bug: command substitution in PROMPT_COMMAND
Chet Ramey wrote: I cannot reproduce this using bash-4.0.10 or bash-4.0.17 on Mac OS X, Ubuntu, RHEL 4, or FreeBSD. Chet I can't reproduce it either. - Ian Kelling
Re: (set -u -e; trap true EXIT; echo $bad) exits 0
Piotr Zielinski 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 pzlaptop 2.6.22-gg15-generic #1 SMP Fri Sep 26 > 12:50:35 EST 2008 i686 GNU/Linux > Machine Type: i486-pc-linux-gnu > > Bash Version: 3.2 > Patch Level: 25 > Release Status: release > > Description: > The following command > > $ (set -u -e; trap true EXIT; echo $bad;) && echo OK > > displays > > bash: bad: unbound variable > OK > > I'd think it should exits with a non-zero error code and not > display OK. This is exacly what happens if you remove -e. Thanks for the report. The problem is that bash doesn't always set $? before testing whether or not the shell should exit because -e has been set and an unset variable is being expanded. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: backward-kill-word is not refreshing correctly
On Mar 18, 6:55 pm, m...@ice.filescope.com, zy...@ice.filescope.com wrote: ... > When I type a long string of text and start pressing ctrl-W to > backwards-kill words, bash deletes the words but doesn't visually refresh > (the words still appear on the command line). This was not occurring for me > in the 3.x series of Bash. > > Repeat-By: > Write this text on the command line: "sample text sample text sample > text sample text sample text". Start pressing ctrl-W and notice it takes a > few kill-words before the words start disappearing. > > --Matt Zyzik I having a problem similar to this. For me, kill-word /never/ refreshes the screen. Additionally, moving up/down through the command history doesn't always cause a refresh either (in a manner deterministic but stochastic). I am using 4.0.17 on arm-apple-darwin9. I also cannot reproduce this problem with bash 3.2. Unfortunately, I cannot reproduce this problem on x86_64-unknown-linux-gnu. I have tried building bash 4.x against ncurses 5.4 and 5.7, I have tried compiling it against a standalone readline 6.x and using a built- in copy, and I have tried compiling both for thumb and arm. I also have tried copying the terminfo database off of my working x86_64 box and I have even tried running without any terminfo database, in the hope of determining why I can't reproduce the problem on my server. Does anyone have any hints on what I could do to debug this? What sections of code this might be using? I know very little about how bash/readline/ncurses work together to handle this problem: even just saying "check out these couple functions" could be useful, so I could start seeing if they are getting called correctly.
Re: backward-kill-word is not refreshing correctly
> > When I type a long string of text and start pressing ctrl-W to > > backwards-kill words, bash deletes the words but doesn't visually refresh > > (the words still appear on the command line). This was not occurring for me > > in the 3.x series of Bash. > I having a problem similar to this. For me, kill-word /never/ > refreshes the screen. Additionally, moving up/down through the command > history doesn't always cause a refresh either (in a manner > deterministic but stochastic). ... > I have tried building bash 4.x against ncurses 5.4 and 5.7, I have > tried compiling it against a standalone readline 6.x and using a built- > in copy, and I have tried compiling both for thumb and arm. And, it turns out that had I tested a standalone readline 5.2, it would have worked fine ;P. The problem was introduced somewhere in readline between bash 3.2 and 4.0. I figured this out by playing with bash some to figure out where it was displaying things to the screen, and then started whittling away at the diff of readline's display.c from 3.2 to 4.0. In the end I managed to isolate it down to the single diff hunk that was causing the problem. It should be made clear that I have no clue what this code is doing, or why it was changed from 3.2 to 4.0: all I know is that the old version worked for me, and this one did not. I am therefore not advocating that removing it is the "correct" fix, and am only providing this information in the hope it will help debug the issue. So, this patch solves my problem, and maybe it will solve Matt's as well: http://svn.telesphoreo.org/trunk/data/readline/lendiff.diff While I'm at it, I highly recommend removing the extraneous CFLAGS overrides from readline's configure.in: they break autoconf's gcc -g detection, if nothing else. http://svn.telesphoreo.org/trunk/data/readline/cflags.diff Sincerely, Jay Freeman (saurik) sau...@saurik.com http://www.saurik.com/
