Re: how to pass arguments with space inside?
On Fri, 10 Apr 2009, Greg Wooledge wrote:
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.
No, it is quite easy without arrays, but not *as* simple. If you
build the strings with a character that is not in the arguments as
a delimiter.
The OP doesn't seem able to grasp either arrays or the meaning of
top posting.
[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?"
--
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)
Re: backward-kill-word is not refreshing correctly
Jay Freeman (saurik) 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. > >> 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. I can't reproduce the problem, and it seems to only appear in builds for your iphone. I'm going to need help with it. :-) Please check the values of _rl_last_c_pos and _rl_screenwidth when this code is executed and the problem occurs. It's likely that the former is set incorrectly somewhere, but I can't tell that for sure yet. 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
And help I will definitely attempt. Here are the requested values: col_lendiff = 5 _rl_last_c_pos = 194 _rl_screenwidth = 126 Some random other variables, in case they end up being requested: lendiff = 5 old = 8403456 new = 8457216 ne = 8457410 oe = 8403655 temp = 0 My cursor is definitely not past the end of my screen. This seems to be a bug in the way prompts are handled. I have a ludicrously complex prompt that has a large number of non-printing characters. This issue then only occurs (as one would expect) if the math works out so the total number of characters in the prompt (/including non-printing ones/) plus my true cursor offset from the prompt is past the edge of the screen, but isn't /actually/. And yes, I am definitely being very careful about using \[ and \] to bound my non-printable characters. I even got it down to this very trivial test case, where ... indicates "more numbers to fill space here", so I could easily see "yes, the \[ and \] are placed correctly". ;P PS1=$'0123456789...0123456789\\[\e[0m\\]' However, even given this knowledge, the bug remains unreproducable on my amd64 box. I have, however, found someone using FreeBSD who said he was seeing related-sounding issues with Bash 4.x, and I know he's also using colored prompts. I am also now confident this is the same problem Matt was having, as once he had killed enough words to get out of the danger region (his prompt was probably not as ludicrous as mine), it started working again. Also, while looking into this (in the hope of reproducing it on Linux), I noticed that in builtins/Makefile.in, LDFLAGS_FOR_BUILD uses LDFLAGS which uses CFLAGS... which is the CFLAGS for the target, not for the build. This became a problem as I tried to do a 32-bit build of bash (using CFLAGS='-O2 -m32 -g') and mkbuiltins.o was compiled without -m32 (as it uses CCFLAGS_FOR_BUILD, which bypasses CFLAGS to use BASE_CCFLAGS) but was being linked with -m32. I do not yet have a correct fix for this unrelated issue. Sincerely, Jay Freeman (saurik) sau...@saurik.com http://www.saurik.com/ - Original Message - From: "Chet Ramey" To: "Jay Freeman (saurik)" Cc: ; ; Sent: Saturday, April 11, 2009 9:14 AM Subject: Re: backward-kill-word is not refreshing correctly ... I can't reproduce the problem, and it seems to only appear in builds for your iphone. I'm going to need help with it. :-) Please check the values of _rl_last_c_pos and _rl_screenwidth when this code is executed and the problem occurs. It's likely that the former is set incorrectly somewhere, but I can't tell that for sure yet. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: DEBUG trap breaks pipelines
l...@upc.ua 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-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 -O2 -g
> -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m64 -mtune=generic
> uname output: Linux fiber.upc.intranet 2.6.20-1.2320.fc5 #1 SMP Tue Jun 12
> 18:50:49 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-redhat-linux-gnu
>
> Bash Version: 3.1
> Patch Level: 17
> Release Status: release
>
> Note: Configuration Information is irrelevant -- same bug in all
> versions(3.1-4.0 inclusive)/OSes(linux,tru64)/machines(alpha,i686,x86_64).
>
> Description:
> {trap "/external/program" DEBUG} breaks pipelining in some ways. When
> trap is set:
>
> 1. A | B pipeline sometimes(*) does not run(**) second part and hungs
> forever.
>sometimes SIGINT(Ctrl+C) revives it, and second part starts.
>(*) in my observation it depends on time, 'A' takes to complete --
> "small" tasks does not triggers that behaviour.
>(**) trap for the "B" part is called, but not the command "B"
> itself
> 2. A & B breaks job control
> 3. (may be not a bug) "$_" no longer contains last arg.
This was interesting. See if the attached patch fixes 1 and 2.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.0-patched/jobs.c 2009-01-29 17:09:49.0 -0500
--- jobs.c 2009-04-11 15:14:27.0 -0400
***
*** 443,447
the_pipeline = saved_pipeline;
already_making_children = saved_already_making_children;
! if (discard)
discard_pipeline (old_pipeline);
}
--- 443,447
the_pipeline = saved_pipeline;
already_making_children = saved_already_making_children;
! if (discard && old_pipeline)
discard_pipeline (old_pipeline);
}
*** ../bash-4.0-patched/trap.c 2009-01-16 17:07:53.0 -0500
--- trap.c 2009-04-11 15:11:58.0 -0400
***
*** 799,802
--- 799,803
{
int trap_exit_value;
+ pid_t save_pgrp;
/* XXX - question: should the DEBUG trap inherit the RETURN trap? */
***
*** 804,808
--- 805,820
if ((sigmodes[DEBUG_TRAP] & SIG_TRAPPED) && ((sigmodes[DEBUG_TRAP] &
SIG_IGNORED) == 0) && ((sigmodes[DEBUG_TRAP] & SIG_INPROGRESS) == 0))
{
+ #if defined (JOB_CONTROL)
+ save_pgrp = pipeline_pgrp;
+ pipeline_pgrp = shell_pgrp;
+ save_pipeline (1);
+ stop_making_children ();
+ #endif
trap_exit_value = _run_trap_internal (DEBUG_TRAP, "debug trap");
+ #if defined (JOB_CONTROL)
+ pipeline_pgrp = save_pgrp;
+ restore_pipeline (1);
+ notify_and_cleanup ();
+ #endif
#if defined (DEBUGGER)
bash associative arrays... my personal trick... waht do you think?
function idx { eval 'case $1 in '${cases[*]}' *) [ "$1" ] && { cases=(
${cases[*]} '\''"'\''$1'\''") echo '${#cases[*]}';;'\'' ); echo
'${#cases[*]}';}; esac'; }
idx all
0
idx all
0
idx jhon
1
idx all
0
as you can see the function return different values for different strings
so associative array becomes quite simple like a simple array
array[`idx name`]=value
echo ${array[`idx name`]}
value
ps this is a more accurate version that make it possible to have more than
one associative array at a time
function idx { eval 'case $1 in '$(eval echo \${${2}_CASES[*]})' *) [ "$1" ]
&& { '$2'_CASES['$(eval echo \${#${2}_CASES[*]})']='\''"'\''$1'\''") echo
'$(eval echo \${#${2}_CASES[*]})';;'\''; echo '$(eval echo
\${#${2}_CASES[*]})';}; esac'; }
array1[`idx name array1`]=value
array2[`idx name array2`]=value
--
---
Tafuni Vito
vitotaf...@gmail.com
-
"Verba volant, scripta manent... data corrupted"
Re: backward-kill-word is not refreshing correctly
> Machine Type: i686-pc-linux-gnu > > Bash Version: 4.0 > Patch Level: 10 > Release Status: release > > Description: > 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. If, as seems likely, this is a problem with the calculation of the physical cursor position, a good place to start would be your PS1 and PROMPT_COMMAND (if any). The locale you're using would be good, too. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
BUG: bash-4.0.17 and SIGWINCH during initialization
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=athlon64 -O2 -pipe -fPIC uname output: Linux lilith 2.6.29.1 #1 PREEMPT Fri Apr 3 03:32:29 CEST 2009 x86_64 AMD Athlon(tm) Processor LE-1620 AuthenticAMD GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.0 Patch Level: 17 Release Status: release Description: There is some kind of race condition in bash-4 (or maybe even readline) when it receives SIGWINCH during initialization. This is a pretty common situation when using a tiled window manager and opening a new terminal. While I didn't had any problems with most terminal applications, the problem manifests with rxvt-unicode and results in bash not reacting on ctrl-c anymore. It happens with bash-4 only, bash-3.x behaved well, even in urxvt. I've had this problem with 4.0, 4.0.10 and 4.0.17 (no other patchlevels tested) As it happens with urxvt only, I reported this problem to the rxvt-unicode mailinglist first but the further discussion there showed the problem is actually a bash-issue (maybe a readline-issue) The difference with urxvt to other terminal applications is it resends SIGWINCH (if received) another time as soon as it receives any output from the application running in it. It does this to fix problems related to SIGWINCH in quite a lot other applications - helping the programs to behave better - especially in tiled window managers. (Un)fortunately it helps bash-4 to make a bug appear, that seems to hide well without this ;) Actually no application should have a problem with receiving SIGWINCH twice, even not during initialization or while the signal handler for a formerly received SIGWINCH is still running. So I decided to move the issue here. During the discussion on the urxvt-mailing list another issue - namely a problem with multiple line prompts not printed correctly also related to early SIGWINCH were reported. Aron Griffis had been able to strace the multi-line prompt problem and posted his results to the rxvt-unicode mailing list. Any try to strace the ctrl-c problem had been without success here, as soon as I strace the problem, it doesn't occure anymore. Both problems seem to have been earlier issues with bash (according to bash's changelog) and it seems that the special behaviour of urxvt just make these problems re-appear? (I'm not sure about this, for me this problems were new) However, I'm not sure if there is any relation between these two problems beside the fact that both are related to SIGWINCH and appear on early SIGWINCH receivement, as the multi-line-prompt problem had been reported to exist in bash-3.2, too. The problem with ctrl-c not working anymore appears to me in bash-4 only. References: The complete discussion on the rxvt-unicode mailinglist can be reviewed in the archive of that mailing list: http://lists.schmorp.de/pipermail/rxvt-unicode/2009q2/thread.html#923 The probably most interesting part is Aron's successful strace of the multi-line prompt-problem, posted here: http://lists.schmorp.de/pipermail/rxvt-unicode/2009q2/000938.html Repeat-By: The problem can be reproduced by running bash-4 with urxvt in a tiled-windowmanager (awesome, dwm, wmii, ion3...) No matter which tiled windowmanager, they all send a SIGWINCH as soon as terminal window opens. The problem can be reproduced without a tiling window manager by calling bash with rxvt-unicode and immediately maximizing the window to trigger SIGWINCH. As it is some race condition, the problem appears something between once in ten times and every time, depending on the system. As mentioned above - the resending of SIGWINCH as soon as any output is received as done by urxvt - seems to be necessary to reproduce the issue. At least I couldn't reproduce it with aterm or xterm, but that doesn't necessarily mean it cannot happen there, the chance it happens might be just more probable due to the resending of SIGWINCH done by rxvt-unicode. Fix: No idea how to fix the problem. I found a workaround only: testing the SHLVL in ~/.bashrc and starting a subshell depending on the value. Obviously not a fix at all, but it makes Ctrl-C working again for me (so I dont feel very much annoyed of it anymore) Thanks: Beside this little problem I really love bash-4. Thanks a lot for developing it. --
