Re: how to pass arguments with space inside?

2009-04-11 Thread Chris F.A. Johnson

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

2009-04-11 Thread Chet Ramey
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

2009-04-11 Thread Jay Freeman (saurik)

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

2009-04-11 Thread Chet Ramey
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?

2009-04-11 Thread Vito Tafuni
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

2009-04-11 Thread Chet Ramey
> 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

2009-04-11 Thread Nicolai Lissner
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.
 
--