Re: crash when using associative array and integer variable

[Roman Rakus]

 On 07/28/2010 08:46 AM, Roman Rakus wrote:

Repeated in the bash-4.0.38 and bash-4.1.7 by the script;
#!/bin/bash

typeset -Ai s
y='*'
z='['
s[$y]=1
s[$z]=2
(( s[$z] = s[$z] + ${s[$y]} ))
(( s[$y] = s[$y] + ${s[$z]} ))
[[ ${s[$y]} = 4  ]] && echo "ok"


FIX: added check;
diff -up bash-4.1/variables.c.Ai bash-4.1/variables.c
--- bash-4.1/variables.c.Ai 2010-07-28 08:42:54.0 +0200
+++ bash-4.1/variables.c2010-07-28 08:43:17.0 +0200
@@ -2371,7 +2371,7 @@ bind_int_variable (lhs, rhs)
 #endif
 v = bind_variable (lhs, rhs, 0);

-  if (isint)
+  if (isint && v)
 VSETATTR (v, att_integer);

   return (v);

RR


Any comments?

RR

Inconsistency of physical / logical directory structure and tab completion

[Roman Rakus]

 $ tree -p
.
├── [-rwxrwxr-x] out_bin
├── [-rw-rw-r--] out_not_bin
├── [drwxrwxr-x] out_of_recursion
└── [drwxrwxr-x] recursion
├── [-rwxrwxr-x] bin
├── [lrwxrwxrwx] in -> ../recursion/
├── [-rw-rw-r--] not_bin
└── [drwxrwxr-x] without

4 directories, 4 files

let's go into recursion dir
$ cd recursion/
$ pwd -L && pwd -P
/home/rrakus/tmp/symlink-test/recursion
/home/rrakus/tmp/symlink-test/recursion

try to tab-complete commands - [TAB] means hitting the tab twice
$ ../[TAB]
out_bin out_of_recursion/ recursion/

$ ./
bin in/ without/

So far, everything is ok. Now go into dir in, which is symlink to 
../recursion/ - current dir

$ cd in/
$ pwd -L && pwd -P
/home/rrakus/tmp/symlink-test/recursion/in
/home/rrakus/tmp/symlink-test/recursion

And now try the tab-completion as above
$ ../[TAB] <--- bug here?
$ ./[TAB]
bin in/ without/

Is that bug? Or expected behaviour?
../out_bin will correctly run that binary
$ ../out_bin
HELLO
$ cat ../out_bin
echo HELLO

However try to complete file names
$ cat ../[TAB]
bin in/ not_bin without/


Trying glob completion works
$ ../*[TAB]
../out_bin ../out_of_recursion ../recursion

However, simple file completion uses logical dir struct, but glob 
completion physical

$ pwd -L && pwd -P
/home/rrakus/tmp/symlink-test/recursion/in
/home/rrakus/tmp/symlink-test/recursion

$ ls ../[TAB]
bin in/ not_bin without/

$ ls ../*
out_bin out_not_bin out_of_recursion recursion

set -P will turn everything to consistent state, however is the above 
considered as expected behaviour or is that a bug?


RR

Re: Inconsistency of physical / logical directory structure and tab completion

[Roman Rakus]

 On 11/10/2010 05:25 PM, Roman Rakus wrote:

 $ tree -p
.
├── [-rwxrwxr-x] out_bin
├── [-rw-rw-r--] out_not_bin
├── [drwxrwxr-x] out_of_recursion
└── [drwxrwxr-x] recursion
├── [-rwxrwxr-x] bin
├── [lrwxrwxrwx] in -> ../recursion/
├── [-rw-rw-r--] not_bin
└── [drwxrwxr-x] without 

Ah, there are missing spaces (at least I see them):
$ tree -p
.
├── [-rwxrwxr-x]  out_bin
├── [-rw-rw-r--]  out_not_bin
├── [drwxrwxr-x]  out_of_recursion
└── [drwxrwxr-x]  recursion
  ├── [-rwxrwxr-x]  bin
  ├── [lrwxrwxrwx]  in -> ../recursion/
  ├── [-rw-rw-r--]  not_bin
  └── [drwxrwxr-x]  without

Hopefully it is better.

RR

Re: Why `echo -n hello | while read v; do echo $v; done' prints nothing?

[Roman Rakus]

On 12/02/2010 12:04 PM, Clark J. Wang wrote:

Following command also prints nothing, confused :(

for ((i = 0; i<  10; ++i)); do echo -n " $i"; done | while read v; do echo
$v; done


read wants to read one line, but you don't end your line.
try this two examples:
$ printf '1 2 3 4' | while read v; do echo $v; done
$ printf '1 2 3 4\n' | while read v; do echo $v; done

RR

Consume only up to 8 bit octal input for backslash-escaped chars (echo, printf)

[Roman Rakus]

This one is already reported on coreutils:
http://debbugs.gnu.org/cgi/bugreport.cgi?msg=2;bug=7574

The problem is with numbers higher than /0377; echo and printf consumes 
all 3 numbers, but it is not 8-bit number. For example:

$ echo -e '\0610'; printf '\610 %b\n' '\610 \0610'
Should output:
10
10 10 10
instead of
�
� � �

So, if the first octal digit is > 3, use up to 2 digits.

Patch follows for echo and printf. Is anything else counting octal values?
RR
---
diff -up bash-4.1/builtins/printf.def.octal bash-4.1/builtins/printf.def
--- bash-4.1/builtins/printf.def.octal 2010-12-07 15:40:24.0 +0100
+++ bash-4.1/builtins/printf.def 2010-12-07 16:13:41.0 +0100
@@ -734,11 +734,15 @@ tescape (estart, cp, sawc)

/* The octal escape sequences are `\0' followed by up to three octal
digits (if SAWC), or `\' followed by up to three octal digits (if
- !SAWC). As an extension, we allow the latter form even if SAWC. */
+ !SAWC). As an extension, we allow the latter form even if SAWC.
+ If the octal character begins with number 4 or higher,
+ only 2 octal digits fit to byte */
case '0': case '1': case '2': case '3':
case '4': case '5': case '6': case '7':
evalue = OCTVALUE (c);
- for (temp = 2 + (!evalue && !!sawc); ISOCTAL (*p) && temp--; p++)
+ for (temp = 2 + (!evalue && !!sawc) -
+ (!sawc ? c > '3' : evalue ? evalue > 3 : *p > '3');
+ ISOCTAL (*p) && temp--; p++)
evalue = (evalue * 8) + OCTVALUE (*p);
*cp = evalue & 0xFF;
break;
diff -up bash-4.1/lib/sh/strtrans.c.octal bash-4.1/lib/sh/strtrans.c
--- bash-4.1/lib/sh/strtrans.c.octal 2008-08-12 19:49:12.0 +0200
+++ bash-4.1/lib/sh/strtrans.c 2010-12-07 15:40:24.0 +0100
@@ -96,6 +96,8 @@ ansicstr (string, len, flags, sawc, rlen
POSIX-2001 requirement and accept 0-3 octal digits after
a leading `0'. */
temp = 2 + ((flags & 1) && (c == '0'));
+ if (*s > '3')
+ temp--;
for (c -= '0'; ISOCTAL (*s) && temp--; s++)
c = (c * 8) + OCTVALUE (*s);
c &= 0xFF;

Re: Consume only up to 8 bit octal input for backslash-escaped chars (echo, printf)

[Roman Rakus]

Sorry for wrong indents. Patch in attachment.

RR
diff -up bash-4.1/builtins/printf.def.octal bash-4.1/builtins/printf.def
--- bash-4.1/builtins/printf.def.octal  2010-12-07 15:40:24.0 +0100
+++ bash-4.1/builtins/printf.def2010-12-07 16:13:41.0 +0100
@@ -734,11 +734,15 @@ tescape (estart, cp, sawc)
 
   /* The octal escape sequences are `\0' followed by up to three octal
 digits (if SAWC), or `\' followed by up to three octal digits (if
-!SAWC).  As an extension, we allow the latter form even if SAWC. */
+!SAWC).  As an extension, we allow the latter form even if SAWC.
+ If the octal character begins with number 4 or higher,
+ only 2 octal digits fit to byte */
   case '0': case '1': case '2': case '3':
   case '4': case '5': case '6': case '7':
evalue = OCTVALUE (c);
-   for (temp = 2 + (!evalue && !!sawc); ISOCTAL (*p) && temp--; p++)
+   for (temp = 2 + (!evalue && !!sawc) -
+ (!sawc ? c > '3' : evalue ? evalue > 3 : *p > '3');
+ ISOCTAL (*p) && temp--; p++)
  evalue = (evalue * 8) + OCTVALUE (*p);
*cp = evalue & 0xFF;
break;
diff -up bash-4.1/lib/sh/strtrans.c.octal bash-4.1/lib/sh/strtrans.c
--- bash-4.1/lib/sh/strtrans.c.octal2008-08-12 19:49:12.0 +0200
+++ bash-4.1/lib/sh/strtrans.c  2010-12-07 15:40:24.0 +0100
@@ -96,6 +96,8 @@ ansicstr (string, len, flags, sawc, rlen
 POSIX-2001 requirement and accept 0-3 octal digits after
 a leading `0'. */
  temp = 2 + ((flags & 1) && (c == '0'));
+  if (*s > '3')
+temp--;
  for (c -= '0'; ISOCTAL (*s) && temp--; s++)
c = (c * 8) + OCTVALUE (*s);
  c &= 0xFF;

Re: Consume only up to 8 bit octal input for backslash-escaped chars (echo, printf)

[Roman Rakus]

On 12/08/2010 02:19 AM, Chet Ramey wrote:

On 12/7/10 11:12 AM, Roman Rakus wrote:

This one is already reported on coreutils:
http://debbugs.gnu.org/cgi/bugreport.cgi?msg=2;bug=7574

The problem is with numbers higher than /0377; echo and printf consumes all
3 numbers, but it is not 8-bit number. For example:
$ echo -e '\0610'; printf '\610 %b\n' '\610 \0610'
Should output:
10
10 10 10
instead of
�
� � �

No, it shouldn't.  This is a terrible idea.  All other shells I tested
behave as bash does*, bash behaves as Posix specifies, and the bash
behavior is how C character constants work.  Why would I change this?

Just wanted to work as coreutils. But ok, you can choose ;)

(*That is, consume up to three octal digits and mask off all but the lower
8 bits of the result.)

Yep. Nothing against this.

Chet


RR

Re: for; do; done regression ?

[Roman Rakus]

On 01/10/2011 05:24 PM, Marc Herbert wrote:

Le 10/01/2011 13:38, Greg Wooledge a écrit :

Don't use seq, ever, because it's Linux-only
and is a stupid way to count when bash has builtin integer arithmetic.")

seq is not exactly Linux-only but GNU-only.

GNU-specific versus bash-specific, which is worse? I'd say it
depends... on which mailing-list you post :-)





I will say the same on both lists - why to execute another process if 
you can do the same in the current one? No gain.


RR

Re: Here strings and pathname expansion

[Roman Rakus]

On 02/14/2011 06:43 AM, Jan Schampera wrote:

Hello world,


I recently answered a question about using the asterisk mixed with 
redirection and other words. This also lead me to the documentation 
that states (REDIRECTION section):


---
The  word  following  the  redirection  operator in the following 
descriptions, unless otherwise noted, is subjected to brace expansion, 
tilde expansion, parameter expansion, command substitution, arithmetic 
expansion, quote removal, pathname expansion, and word splitting.  If 
it expands to more than one word, bash reports an error.

---

It is noted in Here Documents (and Here Strings is a variant of here 
documents). And there is:
No parameter expansion, command substitution, arithmetic expansion,  or 
pathname expansion is performed on word.


This is EITHER
(a) a documentation mistake OR
(b) a bug

Case (c) - bad reading of documentation ;)


Case (a) is clear, the exception is not mentioned.

It is.


RR

Re: compat31

[Roman Rakus]

On 02/14/2011 04:03 PM, Dennis Williamson wrote:

I'm having a discussion with someone who claims that for them on Bash
4.0.33, with compat31*off*, they are getting 3.1 behavior with quoted
patterns in a =~ match.
Is it on Fedora? If so, it was a bug and is fixed since Fedora's 
bash-4.1.2-1 package.


RR

Parse error in case command

[Roman Rakus]

case x"" in.. is falsely parsed. See the example:
$ cat test.sh
case x"" in

  x?) printf "unexpected\n"
 ;;
  x) printf "expected\n"
 ;;
  *) printf "no match\n"
 ;;
esac
$ ./bash ./test.sh
unexpected
$ ./bash --version
GNU bash, version 4.2.6(1)-release (x86_64-unknown-linux-gnu)

x"" is parsed to "x\177" and the \177 is not removed. I'm not sure about 
the right fix. In bash version 4.1.7(1)-release it is parsed to not 
ending \177. I see the difference in expand_word_internal() function. In 
the bash 4.2 there is;

  /* We do not want to add quoted nulls to strings that are only
 partially quoted; we can throw them away. */
  if (temp == 0 && quoted_state == PARTIALLY_QUOTED && 
(word->flags & (W_NOSPLIT|W_NOSPLIT2)))

continue;
where in bash 4.1 there isn't test for word flags. So in bash 4.2 the if 
statement is false and CTLNUL is added to resulting string, but not in 
bash 4.1. I guess there are two possible solutions - Don't add CTLNUL or 
remove it after.


RR

Re: quoting issue in GCC's gcc/config.gcc ?

[Roman Rakus]

On 03/03/2011 07:08 PM, Greg Wooledge wrote:

unset a; case X"${a}" in X) echo good;; *) echo bad;; esac

It's the same as I wrote few seconds before. X"${a}" is parsed to X\117.

RR

Re: quoting issue in GCC's gcc/config.gcc ?

[Roman Rakus]

On 03/03/2011 08:12 PM, Chet Ramey wrote:

Here's a fix.  This is very similar to bash42-004.

Seems it fixed it. But not done more testing.

RR

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

[Roman Rakus]

On 03/08/2011 12:32 PM, Dr. Werner Fink wrote:

Something like the attached patch.

Seems it doesn't work. I have applied your patch, run that bash in 
gnome-terminal, close the terminal. In gdb I set a break to atexit() and 
maybe_save_shell_history() functions. Bash receives SIGHUP, I say 
continue, bash again receives SIGHUP, again continue and bash ends. gdb 
is saying: Program terminated with signal SIGHUP, Hangup.


In man page of atexit:
NOTES
   Functions registered using atexit() (and on_exit(3)) are not 
called  if

   a process terminates abnormally because of the delivery of a signal.

so I guess it won't work.

RR

Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

[Roman Rakus]

On 03/08/2011 06:02 PM, Chet Ramey wrote:

I really wish there was a better solution to the close button problem
than SIGHUP.

+1, or learn people to exit from shell.

RR

Enhancement - hostname in punycode format

[Roman Rakus]

Is there any interest to support hostnames in punycode format? I mean to 
display unicode resresentation rather than ascii (punycode).


RR

Infinite loop in globbing

[Roman Rakus]

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

$ echo $BASH_VERSION
4.2.7(1)-release

$ [$'\xFD'$'\xBA']
^C

The bash 4.2 is in infinite loop. The bash 4.1 work well.

RR

Re: Infinite loop in globbing

[Roman Rakus]

On 03/14/2011 02:59 PM, Greg Wooledge wrote:

On Mon, Mar 14, 2011 at 10:00:14AM +0100, Roman Rakus wrote:

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

$ echo $BASH_VERSION
4.2.7(1)-release

$ [$'\xFD'$'\xBA']
^C

The bash 4.2 is in infinite loop. The bash 4.1 work well.

Can you give more details about the setup here?  Does the glob match
any files or not?
Just need to set some utf8 locales (I guess, tried and using 
en_US.UTF-8). It doesn't matter if the file exists.

In a NON-utf8 locale, with no matching files, I get:

imadev:~$ [$'\xFD'$'\xBA']
bash: [ýº]: command not found


The same here. NON-utf8 locale working. bash-4.1 working also with utf8.

bash-4.2 get stuck in xdupmbstowcs2() static function in do-while loop. 
I know nearly nothing about wide chars so I don't know what is bad here.


Hopefully it helps.

RR

Re: Infinite loop in globbing

[Roman Rakus]

On 03/14/2011 07:36 PM, Chet Ramey wrote:

Here's a minimal patch.

Chet

Thanks. It is working. I mean no infinite loop.

RR

Re: exported variable and tab

[Roman Rakus]

On 03/28/2011 06:56 PM, Matias A. Fonzo wrote:

Hi there,

I have bash 4.2.8(2)-release with readline 6.2 running on GNU/Linux.

I've exported a variable and when I press TAB, the result is a backslash.
For example, with the case of the $HOME variable:

$ mkdir $HOME/test
$ cd $HOME/test

The result is:

cd \$HOME/test

Instead of showing the full path.

Why bash 4.2 is trying to escape an environment variable (expanding with a
directory or a file)?.



Already discussed. See the discussion starting at 
http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00274.html


RR

bashref - FUNCNEST

[Roman Rakus]

The FUNCNEST variable is described unnecessarily twice. In section 3.4 
Shell Functions, pages 16 and 17.


RR

Re: bashref - FUNCNEST

[Roman Rakus]

On 04/05/2011 03:43 PM, Roman Rakus wrote:
The FUNCNEST variable is described unnecessarily twice. In section 3.4 
Shell Functions, pages 16 and 17.


RR
As always I've done mistakes. It is section 3.3. The version of bash is 
4.2 (the latest released).


RR

Re: test -x bug under FreeBSD

[Roman Rakus]

On 04/07/2011 02:30 PM, Igor Prokopenkov wrote:

Hello,
Please take a look at this bug
http://www.freebsd.org/cgi/query-pr.cgi?pr=156225
Any chance to get it fixed?
Thanks.

Already discussed. See 
http://www.mail-archive.com/bug-bash@gnu.org/msg07152.html


RR

bash trap ignore signal - race condition

[Roman Rakus]

There's a race condition when you can hit following:
  set_signal_handler (sig, SIG_IGN);
  change_signal (sig, savestring (string));
  set_signal_handler (sig, trap_handler);
in trap.c file, set_signal() function.
So bash set signal to be ignored and then set it to be handled by 
trap_handler. However how should bash behave when the signal is received 
when the trap_handler has been set before. Check the following reproducer:


#!/bin/bash

cat>  traploop.sh

Re: bash trap ignore signal - race condition

[Roman Rakus]

On 04/12/2011 03:30 PM, Chet Ramey wrote:

Probably because it's very old code.  That has been there essentially
unchanged since at least bash-1.12 -- almost twenty years ago.  It would
be better to block the signal while the trap string and handler are
being modified.

Chet
Thanks for the answer. And what about to not ignore the signal, but use 
some help handler, which will store the information that the signal is 
caught and then after the trap handler is initialized check that 
information? Or some documentation note about this?


RR

Re: bash trap ignore signal - race condition

[Roman Rakus]

On 04/13/2011 03:45 PM, Chet Ramey wrote:

On 4/12/11 11:04 PM, Roman Rakus wrote:

On 04/12/2011 03:30 PM, Chet Ramey wrote:

Probably because it's very old code.  That has been there essentially
unchanged since at least bash-1.12 -- almost twenty years ago.  It would
be better to block the signal while the trap string and handler are
being modified.

Chet

Thanks for the answer. And what about to not ignore the signal, but use
some help handler, which will store the information that the signal is
caught and then after the trap handler is initialized check that
information? Or some documentation note about this?

I'm not sure I understand this.  Why is using a temporary handler better
than blocking the signal until the trap handler is in place, then
unblocking it and allowing any pending signal to be delivered?

Chet
I just want some way to not ignore the signal. For example handle the 
signal after initialization of trap even if the signal is delivered 
during this initialization.

Or document current behavior.

RR

Re: bash trap ignore signal - race condition

[Roman Rakus]

On 04/14/2011 03:07 AM, Roman Rakus wrote:
Or document current behavior. 

What about following?

diff -up bash-4.2/doc/bash.1.trap bash-4.2/doc/bash.1
--- bash-4.2/doc/bash.1.trap2011-04-14 08:10:47.0 +0200
+++ bash-4.2/doc/bash.1 2011-04-14 08:15:34.0 +0200
@@ -9424,6 +9424,7 @@ These are the same conditions obeyed by
 Signals ignored upon entry to the shell cannot be trapped or reset.
 Trapped signals that are not being ignored are reset to their original
 values in a subshell or subshell environment when one is created.
+During trap initialization for specific signal, pending signal can be 
ignored.

 The return status is false if any
 .I sigspec
 is invalid; otherwise


RR

Re: bash trap ignore signal - race condition

[Roman Rakus]

On 04/14/2011 03:09 PM, Chet Ramey wrote:

I'm not sure I understand this.  Why is using a temporary handler better
than blocking the signal until the trap handler is in place, then
unblocking it and allowing any pending signal to be delivered?


I just want some way to not ignore the signal. For example handle the
signal after initialization of trap even if the signal is delivered
during this initialization.

I don't think you are understanding what I'm proposing.  Blocking the signal
with sigprocmask(SIG_BLOCK, ...) does the right thing.


I didn't understand, but now I do. Thanks for clarification and sorry...

RR

Re: Question about arithmetic logic.

[Roman Rakus]

On 04/18/2011 04:30 PM, Steven W. Orr wrote:

I happen to be running

GNU bash, version 4.0.35(1)-release (x86_64-redhat-linux-gnu)

I create an integer variable and assign it either a 0 or a 1. The 
arithmetic test always returns success regardless of value. For example:


typeset -i ss=0

(( ss ))
echo $?# Returns 1. Expected because it should be
# the same as (( ss != 0 )) No?

ss=1
(( ss ))
echo $?# Also says 1. Should this be 0 because it should be the
# success result same as (( ss != 0 ))

But if I use an operator...
ss=0
(( ! ss ))# Says 0.

ss=1
(( ! ss ))# Says 1.

So it seems to me that if I do not use the logical not operator, then 
the arithmetic test is doing a test to see if the string value of ss 
is not null (or something like that). Is this a bug? A feature? Or am 
I doing it wrong?


TIA


I can't reproduce it. Tried bash-4.0.38 and bash-4.1.7

RR

Re: Segfaults on some libtool invocations due to sbrk() assumptions

[Roman Rakus]

On 04/26/2011 09:38 PM, Chet Ramey wrote:

The attached patch fixes the crashes by simply removing the
caching, which is useless anyway since libc already avoids calling the
kernel system call when sbrk is given 0.

Thanks for the patch.  It's dangerous to assume the whole world is
Linux or glibc.

Chet


Hmm... without any knowledge about of the issue or glibc (and forks), I 
like this. Don't assume only glibc, but keep in mind, if it is right. 
This is just a note, just keep it in mind :)


RR

printf builtin - improper error report

[Roman Rakus]

Using bash 4.1.7:
$ printf "ab\nc" > /dev/full
bash: printf: write error: No space left on device
bash: printf: write error: No space left on device

$ /usr/bin/printf "ab\nc" > /dev/full
/usr/bin/printf: write error: No space left on device

The same is on bash 4.2.8.

The second write error is done in PRETURN macro - fflush() sets again 
error bit on stream.


RR

Re: Calling Bash with /S

[Roman Rakus]

On 06/22/2011 06:59 PM, sweinberger wrote:

Hi All,

I am calling bash from dmake.  The make file initiates the call to bash as
follows:

/bin/bash /S /c ""

/bin/bash -S -c ?
Anyway, -S is not valid option in Fedora's bash version 4.1.7.

The command to execute is between the double quotes.  For instance

In Make File:
@ls -l ./SomeDir/*

Bash Command
/bin/bash /S /c "ls -l ./SomeDir/*"

The /S from what I see enables regular expression processing in the bash
command line, but maybe I might be wrong.  In any event, the problem that I
have is the asterisk.  Bash does not like it.  I tried escaping it with a
backslash up to nine levels but that did not work; should only require one.
Pathname expansion is on by default. Can be turned off by `set -f' or 
invoking bash with `-f' option.

Yes, the actual command that I use is not ls.  In the real example, I am
using "rm -f", but ls is a good example too and safer for experimentation.

How do I write the command line, so that it works?  "ls -l ./SomeDir/\*"
does not work, nor anything else that I tried so far.

Explain what means `does not work'. What it does?

Thanks in advance,

Sarah


RR

Re: Question about patterns

[Roman Rakus]

On 06/23/2011 03:59 PM, Steven W. Orr wrote:
I may be wrong, but I think there's a way to do what I want without 
using a regex.


I have a file called foo-1.2-3.tar.gz
I need to set a variable equal to
foo-1.2-i386-x86_64-3.tar.gz

Is there a way to do this without parsing my brains out? I am facile 
with the variable operations like # ## % %% and /, but what I really 
want to do is to say something like


bar=${foo/-([1-9]).tar.gz/-i386-x86_64-\1.tar.gz}

where the \1 is some sort of thing that I can use to refer to a 
backref. Does this exist in bash or do I just do it with a regex?


TIA :-)

Pattern matching in [[ expression ]] and BASH_REMATCH variable are your 
friends (using regex). Anyway, it's possible to do it with parameter 
expansions. In two steps or so...


RR

Re: Question about patterns

[Roman Rakus]

On 06/23/2011 04:56 PM, Roman Rakus wrote:

On 06/23/2011 03:59 PM, Steven W. Orr wrote:
I may be wrong, but I think there's a way to do what I want without 
using a regex.


I have a file called foo-1.2-3.tar.gz
I need to set a variable equal to
foo-1.2-i386-x86_64-3.tar.gz

Is there a way to do this without parsing my brains out? I am facile 
with the variable operations like # ## % %% and /, but what I really 
want to do is to say something like


bar=${foo/-([1-9]).tar.gz/-i386-x86_64-\1.tar.gz}

where the \1 is some sort of thing that I can use to refer to a 
backref. Does this exist in bash or do I just do it with a regex?


TIA :-)

Pattern matching in [[ expression ]] and BASH_REMATCH variable are 
your friends (using regex). Anyway, it's possible to do it with 
parameter expansions. In two steps or so...


RR

$ ./test.sh foo-1.2-3.tar.gz
foo-1.2-i386-x86_64-3.tar.gz

$ cat test.sh
echo ${1%-*}-i386-x86_64-${1##*-}

RR

Re: sorry--this is my question

[Roman Rakus]

On 07/23/2011 02:17 PM, Joachim Schmitz wrote:

Jan Schampera wrote:

On 22.07.2011 18:12, the mad doctor kaeding wrote:

is this a bug?


echo goodbye\ cruel\ world\!

goodbye cruel world!

echo "goodbye cruel world!"

bash: !": event not found

echo "goodbye cruel world\!"

goodbye cruel world\!



No, this is a specific history expansion in interactive shells.

Execute ''set +H'' and try again (it's disabled in non-interactive
shells).


Or use single quotes:

echo 'goodbye cruel world!'

double quotes only prevent filename expansion, but allow 
interpretation of other Shell meta-characters
Not true. Double qutes remove special meaning of characters except `$', 
`\', and, when  history  expansion  is enabled, `!'. Meta characters 
loses its special meaning.


Note: `!' is usual history expansion character, but can be a different 
character.


RR


Bye, Jojo

[PATCH 2/2] Multibyte support for ansic_quote() function

[Roman Rakus]

Correctly check for printable characters using wchar_t* and iswprint().

Signed-off-by: Roman Rakus 
---
 bash-4.2/lib/sh/strtrans.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/bash-4.2/lib/sh/strtrans.c b/bash-4.2/lib/sh/strtrans.c
index 57f9af0..a31bff0 100644
--- a/bash-4.2/lib/sh/strtrans.c
+++ b/bash-4.2/lib/sh/strtrans.c
@@ -212,6 +212,11 @@ ansic_quote (str, flags, rlen)
   if (str == 0 || *str == 0)
 return ((char *)0);
 
+#if defined (HANDLE_MULTIBYTE)
+  wchar_t wcc;
+  size_t wc_len;
+#endif
+
   l = strlen (str);
   rsize = 4 * l + 4;
   r = ret = (char *)xmalloc (rsize);
@@ -222,6 +227,9 @@ ansic_quote (str, flags, rlen)
   for (s = str, l = 0; *s; s++)
 {
   c = *s;
+#if defined (HANDLE_MULTIBYTE)
+  wc_len = 1;
+#endif
   l = 1;   /* 1 == add backslash; 0 == no backslash */
   switch (c)
{
@@ -243,7 +251,12 @@ ansic_quote (str, flags, rlen)
case '\'':
  break;
default:
+#if defined (HANDLE_MULTIBYTE)
+  wc_len = mbrtowc(&wcc, s, MB_CUR_MAX, NULL);
+  if ((int)wc_len < 0 || iswprint(wcc) == 0)
+#else
  if (ISPRINT (c) == 0)
+#endif
{
  *r++ = '\\';
  *r++ = TOCHAR ((c >> 6) & 07);
@@ -256,7 +269,12 @@ ansic_quote (str, flags, rlen)
}
   if (l)
*r++ = '\\';
+#if defined (HANDLE_MULTIBYTE)
+  for (; (int)wc_len > 0; wc_len--, c = wc_len ? *++s : c)
+  *r++ = c;
+#else
   *r++ = c;
+#endif
 }
 
   *r++ = '\'';
-- 
1.7.6

multibyte support for ansic_* functions

[Roman Rakus]

The following two patches add support for multibyte characters in ansic_* 
functions. Effectively it is changing behaviour of:
1) printf's %q format option
2) command not found error message
3) readline's syntax error message
4) XTRACE output

It's a set of two patches.

[PATCH 1/2] Multibyte characters support for ansic_shouldqoute()

[Roman Rakus]

Properly check for printable characters in ansic_shouldqoute().
Use wchar_t* and iswprint() instead of isprint() and char*.

Signed-off-by: Roman Rakus 
---
 bash-4.2/lib/sh/strtrans.c |   26 +-
 1 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/bash-4.2/lib/sh/strtrans.c b/bash-4.2/lib/sh/strtrans.c
index 2265782..57f9af0 100644
--- a/bash-4.2/lib/sh/strtrans.c
+++ b/bash-4.2/lib/sh/strtrans.c
@@ -277,10 +277,34 @@ ansic_shouldquote (string)
   if (string == 0)
 return 0;
 
+#if defined (HANDLE_MULTIBYTE)
+  const wchar_t *wcs;
+  wchar_t wcc;
+
+  wchar_t *wcstr = NULL;
+  size_t wclen, slen;
+
+ 
+  slen = mbstowcs (wcstr, string, 0);
+ 
+  if (slen == -1)
+slen = 0;
+  wcstr = (wchar_t *)xmalloc (sizeof (wchar_t) * (slen + 1));
+  mbstowcs (wcstr, string, slen + 1);
+
+  
+  for (wcs = wcstr; wcc = *wcs; wcs++)
+if (iswprint(wcc) == 0)
+  {
+free (wcstr);
+return 1;
+  }
+  free (wcstr);
+#else
   for (s = string; c = *s; s++)
 if (ISPRINT (c) == 0)
   return 1;
-
+#endif
   return 0;
 }
 
-- 
1.7.6

Re: multibyte support for ansic_* functions

[Roman Rakus]

On 08/16/2011 03:42 PM, Roman Rakus wrote:

The following two patches add support for multibyte characters in ansic_* 
functions. Effectively it is changing behaviour of:
1) printf's %q format option
2) command not found error message
3) readline's syntax error message
4) XTRACE output

It's a set of two patches.




Few more words;
Patches should clearly apply to bash 4.2 with patchlevel 10.
The problem is with locale specific multibyte characters.
ad 1) User can run command `smůla' (Czech word for bad luck) and bash 
will report:

bash: $'sm\305\257la': command not found

With first patch, it will report:
bash: smůla: command not found

The situation is even worse when you use only non-latin characters.
The second patch handles also situations when word contains 
non-printable characters. For example `"smůla "' (tab after).



I think it will improve look and feel. At least calling isprint() 
function on multibyte characters isn't valid.


RR

Re: conditional aliases are broken

[Roman Rakus]

On 08/18/2011 04:38 PM, Sam Steingold wrote:

how do I write a function that would print the same as
$ \ls | cat

f3(){ printf "%s\n" "$@"; }

But please move your question like "HOW TO..." somewhere else; 
comp.unix.shell usenet group or the #bash IRC channel on freenode or...


This mailing list is about bugs in bash.

RR

Re: conditional aliases are broken

[Roman Rakus]

On 08/18/2011 07:57 PM, Eric Blake wrote:

On 08/18/2011 08:53 AM, Roman Rakus wrote:

On 08/18/2011 04:38 PM, Sam Steingold wrote:

how do I write a function that would print the same as
$ \ls | cat

f3(){ printf "%s\n" "$@"; }


"\n" looks funny in shell; even though POSIX requires that "\n" does 
not treat the \ as an escape but as a literal character, 
stylistically, I prefer writing "\\n" or '\n' to make it clear that I 
intended a literal backslash.


Interesting. I would expect that "\\n" in printf will print out `\n'. 
Good to know.


RR

Re: multibyte support for ansic_* functions

[Roman Rakus]

On 08/16/2011 03:42 PM, Roman Rakus wrote:

The following two patches add support for multibyte characters in ansic_* 
functions. Effectively it is changing behaviour of:
1) printf's %q format option
2) command not found error message
3) readline's syntax error message
4) XTRACE output

It's a set of two patches.




Any interest and/or comments here?

RR

Re: multibyte support for ansic_* functions

[Roman Rakus]

On 08/25/2011 02:56 PM, Chet Ramey wrote:

On 8/25/11 8:17 AM, Roman Rakus wrote:

On 08/16/2011 03:42 PM, Roman Rakus wrote:

The following two patches add support for multibyte characters in ansic_*
functions. Effectively it is changing behaviour of:
1) printf's %q format option
2) command not found error message
3) readline's syntax error message
4) XTRACE output

It's a set of two patches.




Any interest and/or comments here?

Interest, yes.  I haven't looked at it closely enough yet to have comments.
This will end up in the next bash release in some form.

Chet


Thanks. Looking forward to new version. I will test it.

RR

Re: segfault with bad array subscript

[Roman Rakus]

On 09/15/2011 08:38 PM, Chet Ramey wrote:

Bash Version: 4.1
Patch Level: 5
Release Status: release

Description:
   Accidentally found the bug. This is what I executed:
 /bin/bash -c 'declare -r a[]=asd'

Thanks for the report.  I'll take a look.

Chet


The crash is in builtins/declare.def on line 541:
  if ((flags_on & (att_exported|att_readonly)) && tempvar_p (var))

var is NULL.

RR

Re: How to match regex in bash? (any character)

[Roman Rakus]

On 09/29/2011 06:18 PM, Peng Yu wrote:

Also, regex(3) does not mention the difference between $x =~ .txt
and $x=~ ".txt". I think that the difference should be addressed
in man bash.

It is in man bash.

RR

Re: [[ str =~ "^pattern" ]] no longer works

[Roman Rakus]

On 11/04/2011 09:09 AM, flong@dell1.localdomain 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  -D_GNU_SOURCE 
-DRECYCLES_PIDS  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux dell1 2.6.32-71.el6.x86_64 #1 SMP Fri May 20 03:51:51 BST 
2011 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu

Bash Version: 4.1
Patch Level: 2
Release Status: release

Description:

 The [[ str =~ "^pattern" ]] operator no longer works correctly.  "^"
 is treated as a literal instead of matching the beginning of the line.

Repeat-By:

 [[ "-h" =~ '^-h' ]] ; echo $?
 Should return 0, but instead returns 1.


It was bug in previous versions of bash in fedora and RHEL.
This behavior is correct now.

RR

Another call of async-signal-unsafe function

[Roman Rakus]

There's a small chance to call unsafe function (malloc) during signal 
handling. It occurs during bash 4.2 startup, when user resize window. 
Occurs on bash configured to use system malloc (not bash malloc).

The stack trace:

#0  __lll_lock_wait_private () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:96
#1  0x003bfec82891 in _L_lock_10436 () from /lib64/libc.so.6
#2  0x003bfec80657 in __GI___libc_malloc (bytes=257680926464) at
malloc.c:2921
#3  0x00468973 in xmalloc (bytes=3) at xmalloc.c:112
#4  0x00436249 in make_variable_value (var=0x10d1860,
value=0x73ae8489 "58", flags=) at variables.c:2176
#5  0x00437247 in bind_variable_internal (name=0x4a7a7e "LINES",
value=0x73ae8489 "58", table=0x10a4830, hflags=, aflags=0)
at variables.c:2234
#6  0x00437ab6 in sh_set_lines_and_columns (lines=,
cols=197) at variables.c:920
#7  0x0049c6fb in _rl_get_screen_size (tty=,
ignore_env=1) at terminal.c:299
#8  0x0049c8ec in rl_resize_terminal () at terminal.c:353
#9  0x00499372 in rl_sigwinch_handler (sig=28) at signals.c:260
#10
#11 _int_malloc (av=0x3bfefae700, bytes=1024) at malloc.c:3868
#12 0x003bfec80665 in __GI___libc_malloc (bytes=1024) at malloc.c:2924
#13 0x00468973 in xmalloc (bytes=1024) at xmalloc.c:112
#14 0x00494ca7 in init_line_structures (minsize=) at
display.c:481
#15 0x00498879 in rl_redisplay () at display.c:522
#16 0x00487ad1 in readline_internal_setup () at readline.c:445
#17 0x0048890d in readline_internal () at readline.c:643
#18 e (prompt=) at readline.c:388
#19 0x0041e45c in yy_readline_get () at ./parse.y:1443
#20 0x004203b9 in yy_getc () at ./parse.y:1376
#21 shell_getc (remove_quoted_newline=1) at ./parse.y:2231
#22 shell_getc (remove_quoted_newline=1) at ./parse.y:2159
#23 0x00422d56 in read_token (command=) at
./parse.y:2908
#24 read_token (command=0) at ./parse.y:2859
#25 0x0042581d in yylex () at ./parse.y:2517
#26 yyparse () at y.tab.c:2031
#27 0x0041dd1a in parse_command () at eval.c:229
#28 0x0041dde6 in read_command () at eval.c:273
#29 0x0041e033 in reader_loop () at eval.c:138
#30 0x0041c79f in main (argc=1, argv=0x73ae9e58,
env=0x73ae9e68) at shell.c:759


RR

Re: set -e works incorrectly in subshells

[Roman Rakus]

On 11/23/2011 11:26 AM, Марк Коренберг 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 mmarkk-work 2.6.38-12-generic #51-Ubuntu SMP Wed
Sep 28 14:27:32 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.2
Patch Level: 8
Release Status: release

Repeat-By:
mmarkk@mmarkk-work:~$ ( set -e; echo aaa; false; echo bbb )
aaa
mmarkk@mmarkk-work:~$ ( set -e; echo aaa; false; echo bbb ) || true
aaa
bbb
mmarkk@mmarkk-work:~$
Expect:
mmarkk@mmarkk-work:~$ ( set -e; echo aaa; false; echo bbb )
aaa
mmarkk@mmarkk-work:~$ ( set -e; echo aaa; false; echo bbb ) || true
aaa
mmarkk@mmarkk-work:~$mmarkk@mmarkk-work:~$


Not a bug.
See man page of set builtin; quoting:
 The shell does not
exit  if  the  command that fails is part of the command
list immediately following a  while  or  until  keyword,
part  of  the  test  following  the  if or elif reserved
words, part of any command executed in a && or  ||  list
except  the  command  following  the final && or ||, any
command in a pipeline but the last, or if the  command's
return  value  is being inverted with !.

Re: Bash git repository on savannah

[Roman Rakus]

On 11/28/2011 06:28 AM, Mike Frysinger wrote:

I don't think I'll push every change to git as soon as it happens, but
>  I'm thinking about fairly frequent commits to a `bash-devel' sort of
>  tree.  The question is whether or not enough people would be interested
>  in that to make the frequency worth it.

i would;)
-mike

me too

RR

Re: '>;' redirection operator

[Roman Rakus]

Feel free to write a patch.

RR

Process group id of first command in command substitution (bash4 vs bash3)

[Roman Rakus]

I'm not sure if it's a bug or not, but there is change between old bash 
3.2 and bash 4.2.

When you run a script:
set -m
$(sleep 1; sleep 2)

in bash 4.2 the first sleep has same group id as parent shell. However 
in bash 3.2 it has different group id.


Is it bug or not? I'm not able to find documentation for this change. 
And seems that POSIX says nothing about it.


RR

Re: Process group id of first command in command substitution (bash4 vs bash3)

[Roman Rakus]

On 02/20/2012 10:57 PM, Chet Ramey wrote:

I'm not sure if it's a bug or not, but there is change between old bash
3.2 and bash 4.2.
When you run a script:
set -m
$(sleep 1; sleep 2)

in bash 4.2 the first sleep has same group id as parent shell. However
in bash 3.2 it has different group id.

Is it bug or not? I'm not able to find documentation for this change.
And seems that POSIX says nothing about it.

How could this possibly matter?


It could matter in sending (receiving) signal to process group.

RR

Re: Pathname expansion not performed in Here Documents

[Roman Rakus]

On 02/27/2012 01:50 PM, Steven W. Orr wrote:
I don't mean this in a snarky way, but shell man pages are 
historically in the class of docs that you really need to read over 
and over again. There are a few books on shell programming, most of 
them not very good, but I personally have read the bash man pages 
literally thousands of times and before I'm dead, I expect to multiply 
that many times over. There are really good web pages that people have 
put a lot of of time and energy into, and those are not to be 
dismissed. The idea is to assemble your resources enough that you can 
know where to go to answer a specific question. In between those 
questions, you really need to re-read your reference material on a 
regular basis.


It never ends. :-) 
I'm using searching on man page and also bash reference manual is quite 
usable (at least it has index).


RR

Re: Inconsistent quote and escape handling in substitution part of parameter expansions.

[Roman Rakus]

On 02/28/2012 10:17 AM, lhun...@lyndir.com wrote:

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin11.2.0
Compiler: /Developer/usr/bin/clang
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='darwin11.2.0' -DCONF_MACHTYPE='i386-apple-darwin11.2.0' 
-DCONF_VENDOR='apple' -DLOCALEDIR='/opt/local/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H -DMACOSX   -I.  -I. -I./include -I./lib  
-I/opt/local/include -pipe -O2 -arch x86_64
uname output: Darwin mbillemo.lin-k.net 11.3.0 Darwin Kernel Version 11.3.0: 
Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
Machine Type: i386-apple-darwin11.2.0

Bash Version: 4.2
Patch Level: 20
Release Status: release

Description:
The handling of backslash and quotes is completely inconsistent, 
counter-intuitive and in violation of how the syntax works elsewhere in bash.

 ' appears to introduce a single-quoted context and \ appears to escape 
special characters.  That's good.
 A substitution pattern of ' causes bash to be unable to find the closing 
quote.  That's good.
 A substitution pattern of '' SHOULD equal an empty quoted string.  The 
result, however, is ''.  That's NOT good.  Suddenly the quotes are literal?
 A substitution pattern of '$var' SHOULD disable expansion inside the 
quotes. The result, however, is '[contents-of-var]'.  That's NOT good.  In 
fact, it looks like quoting doesn't work here at all.
 \\ is a disabled backslash, and the syntactical backslash is removed.  The 
result is \.  That's good.
 \' is a disabled single quote, but the syntactical backslash is NOT 
removed.  The result is \'.  That's NOT good.

 It mostly looks like all the rules for handling quoting and escaping are 
out the window and some random and utterly inconsistent set of rules is being 
applied instead.

Fix:
Change parsing of the substitution pattern so that it abides by all the 
standard documented rules regarding quotes and escaping.

Can you please elaborate more? Do you mean Pattern substitution? The 
reproducer (example) will help a lot.


RR

Re: Inconsistent quote and escape handling in substitution part of parameter expansions.

[Roman Rakus]

On 02/28/2012 02:36 PM, Chet Ramey wrote:

On 2/28/12 4:17 AM, lhun...@lyndir.com wrote:

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin11.2.0
Compiler: /Developer/usr/bin/clang
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='darwin11.2.0' -DCONF_MACHTYPE='i386-apple-darwin11.2.0' 
-DCONF_VENDOR='apple' -DLOCALEDIR='/opt/local/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H -DMACOSX   -I.  -I. -I./include -I./lib  
-I/opt/local/include -pipe -O2 -arch x86_64
uname output: Darwin mbillemo.lin-k.net 11.3.0 Darwin Kernel Version 11.3.0: 
Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
Machine Type: i386-apple-darwin11.2.0

Bash Version: 4.2
Patch Level: 20
Release Status: release

Description:
The handling of backslash and quotes is completely inconsistent, 
counter-intuitive and in violation of how the syntax works elsewhere in bash.

 ' appears to introduce a single-quoted context and \ appears to escape 
special characters.  That's good.
 A substitution pattern of ' causes bash to be unable to find the closing 
quote.  That's good.
 A substitution pattern of '' SHOULD equal an empty quoted string.  The 
result, however, is ''.  That's NOT good.  Suddenly the quotes are literal?
 A substitution pattern of '$var' SHOULD disable expansion inside the 
quotes. The result, however, is '[contents-of-var]'.  That's NOT good.  In 
fact, it looks like quoting doesn't work here at all.
 \\ is a disabled backslash, and the syntactical backslash is removed.  The 
result is \.  That's good.
 \' is a disabled single quote, but the syntactical backslash is NOT 
removed.  The result is \'.  That's NOT good.

 It mostly looks like all the rules for handling quoting and escaping are 
out the window and some random and utterly inconsistent set of rules is being 
applied instead.

Fix:
Change parsing of the substitution pattern so that it abides by all the 
standard documented rules regarding quotes and escaping.

It would go better if you gave some examples of what you consider
incorrect behavior.  This description isn't helpful as it stands.


Maybe something like this:

# ttt=ggg
# ggg="asd'ddd'g"
# echo "'${!ttt//\'/'\''}'"

 ^C

# echo "'${!ttt//\'/\'\\\'\'}'"
'asd\'\\'\'ddd\'\\'\'g'



Anyway, I thought that single quote retains its special meaning in 
double quotes.

$ echo "'a'"
'a'

RR

Re: Inconsistent quote and escape handling in substitution part of parameter expansions.

[Roman Rakus]

On 02/28/2012 05:10 PM, John Kearney wrote:

wrap it with single quotes and globally replace all single quotes in the
string with '\''
single quote and slash have special meaning so they have to be escaped, 
that's it.

\'${var//\'/\\\'}\'
it is not quoted, so it undergoes word splitting. To avoid it quote it 
in double quotes, however it changes how slash and single quote is treated.

"'${var//\'/\'}'"

Wasn't it already discussed on the list?

RR

Re: Inconsistent quote and escape handling in substitution part of parameter expansions.

[Roman Rakus]

On 02/28/2012 05:22 PM, Roman Rakus wrote:

On 02/28/2012 05:10 PM, John Kearney wrote:

wrap it with single quotes and globally replace all single quotes in the
string with '\''
single quote and slash have special meaning so they have to be 
escaped, that's it.

\'${var//\'/\\\'}\'
it is not quoted, so it undergoes word splitting. To avoid it quote it 
in double quotes, however it changes how slash and single quote is 
treated.

"'${var//\'/\'}'"

Wasn't it already discussed on the list?

RR

And that means, there isn't way to substitute "something" to ' (single 
quote) when you want to not perform word splitting. I would consider it 
as a bug.


RR

Re: Inconsistent quote and escape handling in substitution part of parameter expansions.

[Roman Rakus]

On 02/28/2012 05:49 PM, Greg Wooledge wrote:

On Tue, Feb 28, 2012 at 05:36:47PM +0100, Roman Rakus wrote:

And that means, there isn't way to substitute "something" to ' (single
quote) when you want to not perform word splitting. I would consider it
as a bug.

imadev:~$ q=\'
imadev:~$ input="foosomethingbar"
imadev:~$ echo "${input//something/$q}"
foo'bar

I meant without temporary variable.

RR

Re: using the variable name, GROUPS, in a read list

[Roman Rakus]

On 03/07/2012 04:54 PM, Jim Meyering wrote:

FYI, if I attempt to read into the built-in array variable, GROUPS,
this doesn't work:

   $ bash -c 'while read GROUPS; do echo $GROUPS; done<  /etc/passwd'|wc -l
   0

Comparing with dash, I see what the author expected, i.e.,
that the while loop iterates once per line in /etc/passwd:

   $ dash -c 'while read GROUPS; do echo $GROUPS; done<  /etc/passwd'|wc -l
   57

With bash, I can work around that by first doing "unset GROUPS".

Is there a moral here, other than to avoid using special variable names?
Probably to prefer lower-case variable names.


GROUPS An  array  variable  containing  the list of groups of which the
  current user is a member.  Assignments to GROUPS have no  
effect
  and  return  an  error status.  If GROUPS is unset, it 
loses its

  special properties, even if it is subsequently reset.

$ read GROUPS <<< "a"; echo $?
1

RR

Re: [bug] Home dir in PS1 not abbreviated to tilde

[Roman Rakus]

On 03/13/2012 04:08 PM, dethrophes wrote:

Am 13.03.2012 06:04, schrieb Clark J. Wang:

On Mon, Mar 12, 2012 at 12:22, Yongzhi Pan  wrote:


Tested in GNU bash, version 3.00.16(1)-release and 4.1.2(1)-release.

Upon login, home dir is displayed as tilde in PS1:
pan@BJ-APN-2 ~$ echo $PS1
\[\033[35m\]\u@\h \w$ \[\033[0m\]
pan@BJ-APN-2 ~$ pwd
/export/home/pan/

After a cd command, which change directory to $HOME (not changed at 
all),

it is displayed as the complete path:
pan@BJ-APN-2 ~$ cd
pan@BJ-APN-2 /export/home/pan$

The reason is that my home in passwd has a trailing slash:
pan@BJ-APN-2 /export/home/pan$ grep ^$USER: /etc/passwd
pan:x:896:1::/export/home/pan/:/bin/bash


You can also reproduce this by directly setting HOME to
`/export/home/pan/'.


This is tricky to find. I hope it will display tilde even if home 
dir entry

in passwd has one or more trailing slash.


I personally don't think this needs to be fixed. :)

I agree, or to be more acurate I think you should fix the passwd entry.

PS: I read the source code and do not know where this is done, maybe in
y.tab.c?



as a workaround to your problem you could have something like this in 
your bashrc

if shopt extglob &>/dev/null ; then
  HOME="${HOME/%+(\/)}"   # strip all trailing forward slashes
else
   while [ "${HOME}" != "${HOME%\/}" ] ; do
 HOME="${HOME%\/}"
   done
fi

I think it should hide your problem.





Is it all necessary?
HOME="${HOME%\/}"

RR

Re: Process group id of first command in command substitution (bash4 vs bash3)

[Roman Rakus]

On 03/10/2012 09:30 PM, Chet Ramey wrote:

On 2/20/12 1:25 PM, Roman Rakus wrote:

I'm not sure if it's a bug or not, but there is change between old bash 3.2
and bash 4.2.
When you run a script:
set -m
$(sleep 1; sleep 2)

in bash 4.2 the first sleep has same group id as parent shell. However in
bash 3.2 it has different group id.

Is it bug or not? I'm not able to find documentation for this change. And
seems that POSIX says nothing about it.

The intent of the bash code has always been that the process group of
commands running command substitutions be the same as the parent shell.
That way they can get the same signals.  I read Posix as supporting this
interpretation, since the -m option applies to jobs and command
substitutions are not jobs.

Chet

OK, so it was bug in previous versions of bash.

RR

Re: Directory completion problems

[Roman Rakus]

On 04/19/2012 12:28 PM, Artur Rataj wrote:

~/projects/art/dev/lib$ cd ../
.bzr/ lib/
~/projects/art/dev/lib$ cd ../src
~/projects/art/dev/src$ cd ../
.bzr/ lib/ src/
~/projects/art/dev/src$ cd ../lib
~/projects/art/dev/lib$ cd ../
.bzr/ lib/

Are there any symlinks?

RR

Re: Severe Bash Bug with Arrays

[Roman Rakus]

On 04/25/2012 06:15 PM, Chet Ramey wrote:

On 4/25/12 11:27 AM, Greg Wooledge wrote:

On Wed, Apr 25, 2012 at 11:07:57AM -0400, Chet Ramey wrote:

z4.local(1)$ ../bash-4.2-patched/bash -c 'echo $BASH_VERSION'
4.2.24(9)-release
z4.local(1)$ ../bash-4.2-patched/bash ./x3
foo
z4.local(1)$ ./x3
foo

I grabbed patches 21-24 and applied them.  No change.

OK.  I get the same working behavior on Mac OS X, Solaris 8/10, RHEL 5,
BSD/OS (old), and Fedora 15.  I'm not sure what to tell you.

Chet

On Fedora 16 it works as expected.
$ rpm -q bash
bash-4.2.24-1.fc16.x86_64

RR

Re: Possible bug: Race condition when calling external commands during trap handling

[Roman Rakus]

On 05/22/2012 02:28 PM, Greg Wooledge wrote:

I do not know the answers to "How does bash implement traps?  Is there
a guarantee that no signals will be lost?"  Hopefully someone else does.
I can just imagine a situation when the bash is reading trap from the 
source (is going through the script and is on line where trap is) or not 
read it yet and the signal is received. Then, of course, your trap 
handler is not installed yet.
Another situation: You had previous trap handler and you are installing 
new one. The received signals are "paused" for a while and are processed 
right after the installation of new trap handler. There was a bug report 
against this, I'm not sure if it is fixed.


RR

Re: Possible bug: Race condition when calling external commands during trap handling

[Roman Rakus]

On 05/22/2012 03:01 PM, Chet Ramey wrote:

On 5/22/12 8:41 AM, Roman Rakus wrote:


Another situation: You had previous trap handler and you are installing new
one. The received signals are "paused" for a while and are processed right
after the installation of new trap handler. There was a bug report against
this, I'm not sure if it is fixed.

Can you provide a reference to that report?



http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00045.html

RR

Re: Red-Hat Bug 825751 - bash-completion fails on environment variables

[Roman Rakus]

On 06/07/2012 11:22 PM, Linda Walsh wrote:

In reading the messages quoted above, I'm not sure some people
understand the severity of the bug.

I do not.
And many people don't understand expansions, quoting, completions and 
many other...


This isn't a matter of preference... its a real bug.

Ex:
$ ls $HOME/bin
"ls: cannot access $HOME/bin: No such file or directory"

quoting and completion


It's not about expansion or non-expansion during the editing phase--
that would be a matter of preference, it's that when you hit enter,
it doesn't expand the variables -- which I can't see being useful for
anyone.

Note -- this is the same type of problem as Bash not correcting
the case of path components.

Why would bash do that?


Bash isn't correcting the lines anymore so that final
expansions match real paths...


When I originally heard this discussion, I thought -- it's a matter
of preference, though I think I prefer expansion, I could see times
when it might be a hassle (if the var was a REAL long expansion,
it might overflow the line)...but having it not work at all...

That's not useful for anyone.


And to be complete, there is a bug also in bash-completion package, 
which need to be fixed.

Many people uses bash-completion, even they don't know it.

RR

Re: bash tab variable expansion question?

[Roman Rakus]

On 06/11/2012 11:07 AM, John Embretsen wrote:

On 06/11/2012 10:10 AM, Pierre Gaston wrote:
On Mon, Jun 11, 2012 at 10:59 AM, John Embretsen  
wrote:

On 27 Feb 2011 18:18:24 -0500, Chet Ramey wrote:

On Sat, Feb 26, 2011 at 10:49 PM, gnu.bash.bugwrote:
A workaround is fine but is the 4.2 behavior bug or not?


It's a more-or-less unintended consequence of the requested change 
Eric

Blake referred to earlier in the thread.


http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00275.html

(...)


The question is how to tell readline that the `$' should be quoted
under some circumstances but not others.  There's no hard-and-fast
rule that works all the time, though I suppose a call to stat(2)
before quoting would solve part of the problem.  I will have to give
it more thought.

Chet


Any updates on this issue?


(...)



There have been many updates on this. There have been a "fix"
available for some time now on this list .

It is now available as an official patch
ftp://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-029


Thank you. For someone like me who is not active in this project it 
seems it is not very easy to keep track of bugs, patches and releases. 
Is there an issue number/bug number of some sort for this particular 
issue that I could use for this purpose?
There isn't any tracker for (upstream) bash. At least I don't know about 
any.


I hope the patch works well enough and that it will end up in Linux 
distros shortly.



Fedora already has it. But there is also (the same?) bug in 
bash-completion, which is reported upstream.


RR

Re: regex in bashexpression doesn't work

[Roman Rakus]

On 06/25/2012 09:18 AM, Niels Carl W. Hansen 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 -DRECYCLES_PIDS  
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
uname output: Linux in 2.6.32-220.17.1.el6.x86_64 #1 SMP Wed May 16 00:01:37 
BST 2012 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 4.1
Patch Level: 2
Release Status: release

Description:
 [[ 'foobar'  =~ 'o.a' ]] && echo FOUND
 should print  FOUND  but it doesn't.
 This have worked in previeous versions of bash.
 The bash used comes with CentOS 6.2

Repeat-By:
 No privous commands necessary to generate this problem.

Fix:


There is  a bug in previous versions of bash in Fedora, RHEL and CentOS. 
It means, in those distributions, bash versions up to 4.0 treats quoting 
differently than upstream.
If you want to use the same quoting you have to enable compat31 shell 
option.


RR

Re: Massive recursion -> SEGV

[Roman Rakus]

On 07/01/2012 02:03 PM, Jan Schampera wrote:

Hi folks,


a suggestion about recursive function calls (and not only that, of 
course).


Do you see a way for Bash to pull the emergency break before it runs 
out of stack here (to provide an error to the user, rather than a crash):



f1() {
  f1
}

f1


Currently it runs into a SEGV, where the number of recurions depends 
on the stack limit.


On a fast search I found no portable way, but there are ways for 
specific platforms, like getrusage() when stack is reported there.



Look for FUNCNEST variable. In recent release it is available.

RR

Re: retrun value of buildin (( )) / GNU bash, version 4.2.24(1)-release (x86_64-pc-linux-gnu)

[Roman Rakus]

On 07/10/2012 05:32 PM, Orlob Martin (EXT) wrote:

Hallo,

I was using the build in (( )) function for  count up an index. I think I found 
a bug in GNU bash, version 4.2.24(1)-release (x86_64-pc-linux-gnu).

((expression)) is one of Compound Commands (not builtin nor function).
Quoting the manual page:
((expression))
The expression is evaluated according to the rules described
below under ARITHMETIC EVALUATION. If the value of the expres‐
sion is non-zero, the return status is 0; otherwise the return
status is 1. This is exactly equivalent to let "expression".

See also a comment below inline.


The (( )) function is working fine, but the corresponding return value does not 
match.
  Check following small example (have the focus on $?)

--SCRIPT START-
#!/bin/bash

index=-3
for a in 1 2 3 4 5 6 7  ; do
 echo "Index before: $index"
 (( index++ ))
   echo "Return value: $?"
   echo "Index after: $index"
   echo ""
done
--SCRIPT END--

OUTPUT is:


Index before: -3
Return value: 0
Index after: -2

Index before: -2
Return value: 0
Index after: -1

Index before: -1
Return value: 0
Index after: 0

Index before: 0
Return value: 1<-- ?BUG? The index was counted up correctly, from 0 to 1, but return 
value of (( ))-function is "1"
No, works like intended. index value is 0 (zero) and thus return value 
of (( )) is 1. And the value of index is post-incremented.

Index after: 1

Index before: 1
Return value: 0
Index after: 2

Index before: 2
Return value: 0
Index after: 3

Index before: 3
Return value: 0
Index after: 4


Cheers,

Martin







--
Martin Orlob - Systemintegrator

Im Auftrag der
e.solutions GmbH
GVZ Halle N West / Eingang A,
Pascalstraße 5, 85057 Ingolstadt, Germany

Registered Office:
Pascalstr. 5, 85057 Ingolstadt, Germany

Phone +49-8458-3332-702
Fax +49-8458-3332-20130
mailto: 
extern.martin.or...@esolutions.de

e.solutions GmbH
Managing Directors Uwe Reder, Dr. Riclef Schmidt-Clausen
Register Court Ingolstadt HRB 5221

Re: AIX and Interix also do early PID recycling.

[Roman Rakus]

On 07/25/2012 04:52 PM, Michael Haubenwallner wrote:

Got it: The value used for js.c_childmax isn't 128, but 1024.

In lib/sh/oslib.c, getmaxchild() prefers sysconf(_SC_CHILD_MAX) over CHILD_MAX 
over MAXUPRC.

But sysconf(_SC_CHILD_MAX) does return the number of "processes per real user 
id" (similar to
ulimit -u), rather than the number of CHILD_MAX (whenever defined).

For Interix, things are different though:
There is no CHILD_MAX nor MAXUPRC defined, and sysconf(_SC_CHILD_MAX) does 
return 512,
but PIDs start to be recycled at ~120 already...

Any idea about the "correct" fix for getmaxchild() across platforms?

/haubi/


And there is also a problem when you change the `ulimit -u' value.
See  https://bugzilla.redhat.com/show_bug.cgi?id=832997

RR

Re: AIX and Interix also do early PID recycling.

[Roman Rakus]

On 07/25/2012 07:12 PM, Chet Ramey wrote:

On 7/25/12 10:57 AM, Roman Rakus wrote:


And there is also a problem when you change the `ulimit -u' value.
See  https://bugzilla.redhat.com/show_bug.cgi?id=832997

It's not clear to me that it's desirable to attempt to remember a
potentially unlimited number of process exit statuses.  You have to
bound it somewhere.

Chet
Hmm... I don't know much about boundaries of maximum number of user 
processes. But anyway - do you think that (re)changing js.c_childmax 
(when `ulimit -u' is changed) is not good?


RR

Re: bash does filename expansion when assigning to array member in compound form

[Roman Rakus]

On 08/20/2012 07:12 PM, Gundi Cress wrote:

Am Sat, 18 Aug 2012 19:55:17 +0100 schrieb Stephane Chazelas:


2012-08-18 10:26:22 -0500, Dan Douglas:

This is a feature that all shells with this style of compound
assignment have in common. If no explicit subscripts are given, the
text between the parentheses is processed exactly as though it were
arguments to a command including brace expansion, word-splitting, and
pathname expansion (and consequently, quoting is just as important).
This is an important feature because it allows storing the results of a
glob in an array easily.

If a subscript is given explicitly, then the right-hand side of the
assignment is treated exactly as an ordinary scalar assignment would
be, including all analagous behaviors for `+=' and the integer
attribute.

  $ set -x; a=( [1]=* )
+ a=([1]=*)

[...]

Nope:

~/1$ touch '[1]=x'
~/1$ bash -c 'a=( [1]=* ); echo "${a[@]}"' [1]=x ~/1$ bash -c 'a=(
[1]=asd ); echo "${a[@]}"'
asd

That's a bug though.


I'm not sure if I got it right.
Please correct me if I got it wrong:

It is not generally a bug that Bash does filename expansion when assigning
to array members in compound form. Only if explicit indices identify
array members in a compound assignment there should be no filename
expansion and it's a bug if Bash does so.


Gundi

   



And how would you achieve to fill array with all file names containing 
`[1]=' for example.
Definitely it's good, if you want to be sure, to always quote all 
characters which means pathname expansion - `*', `?' and `['.


RR

Re: AIX and Interix also do early PID recycling.

[Roman Rakus]

On 08/01/2012 03:13 PM, Chet Ramey wrote:

On 7/30/12 10:41 AM, Roman Rakus wrote:


Hmm... I don't know much about boundaries of maximum number of user
processes. But anyway - do you think that (re)changing js.c_childmax (when
`ulimit -u' is changed) is not good?

Maybe it's ok up to some fixed upper bound.  But if you're going to have
that fixed upper bound, why not just use it as the number of job exit
statuses to remember all the time?

I prepared a patch which add configure option to enable and set the 
number of job exit statuses to remember.
I found that posix is talking about changing system configurable 
variables and values; quoting:

"""
This runtime facility is not meant to provide ever-changing values that 
applications have to check multiple times. The values are seen as 
changing no more frequently than once per system initialization, such as 
by a system administrator or operator with an automatic configuration 
program. This volume of POSIX.1-2008 specifies that they shall not 
change within the lifetime of the process.

"""
(see http://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html)
So I would tell that bash does not need to check every time maxchild value.
However, when the maxchild is set to unlimited, now the bash will use 
predefined DEFAULT_CHILD_MAX which is set to 32.
The attached patch adds ability to set forced number of remembered 
statuses, easily during configure time, example:

 ./configure --enable-fixedjsmax=2048
It will force bash to remember 2048 statuses, independently on childmax 
value.

Patch should clearly apply to git master branch.
Chet, what do you think about it?

RR
>From 32701d12fc6ddf8e3289ea920423c0e55210e3a5 Mon Sep 17 00:00:00 2001
From: Roman Rakus 
Date: Thu, 23 Aug 2012 19:35:52 +0200
Subject: [PATCH] Option to use fixed number of remembered job exit statuses

Signed-off-by: Roman Rakus 
---
 config.h.in  |  3 +++
 configure.in | 13 +
 jobs.c   |  8 
 3 files changed, 24 insertions(+)

diff --git a/config.h.in b/config.h.in
index 6b1fc4a..b09b939 100644
--- a/config.h.in
+++ b/config.h.in
@@ -1125,6 +1125,9 @@
 
 /* End additions for lib/intl */
 
+/* Define if you want to use fixed number of remembered job exit statuses */
+#undef USE_FIXEDJSMAX_NUMBER
+
 #include "config-bot.h"
 
 #endif /* _CONFIG_H_ */
diff --git a/configure.in b/configure.in
index d7e0998..dd5e0c9 100644
--- a/configure.in
+++ b/configure.in
@@ -1107,6 +1107,19 @@ case "$srcdir" in
 	;;
 esac
 
+AC_MSG_CHECKING([whether to use fixed number of remembered job exit statuses])
+AC_ARG_ENABLE([fixedjsmax],
+  [AS_HELP_STRING([--enable-fixedjsmax=number],
+ [Enable fixed number of remembered job exit statuses])],
+  [ENABLE_FIXEDJSMAX="${enableval}"], [ENABLE_FIXEDJSMAX='no'])
+AC_MSG_RESULT(${ENABLE_FIXEDJSMAX})
+if test "x${ENABLE_FIXEDJSMAX}" != xno; then
+  AS_IF([test "${ENABLE_FIXEDJSMAX}" -gt "0" 2>/dev/null],
+AC_DEFINE_UNQUOTED(USE_FIXEDJSMAX_NUMBER, [${ENABLE_FIXEDJSMAX}]),
+AC_MSG_ERROR([invalid value]))
+fi
+
+
 BUILD_DIR=`pwd`
 case "$BUILD_DIR" in
 *\ *)	BUILD_DIR=`echo "$BUILD_DIR" | sed 's: : :g'` ;;
diff --git a/jobs.c b/jobs.c
index d63c5dd..7744b5e 100644
--- a/jobs.c
+++ b/jobs.c
@@ -3723,9 +3723,13 @@ initialize_job_control (force)
 get_tty_state ();
 
   if (js.c_childmax < 0)
+#if defined (USE_FIXEDJSMAX_NUMBER)
+js.c_childmax = USE_FIXEDJSMAX_NUMBER;
+#else
 js.c_childmax = getmaxchild ();
   if (js.c_childmax < 0)
 js.c_childmax = DEFAULT_CHILD_MAX;
+#endif
 
   return job_control;
 }
@@ -4092,9 +4096,13 @@ mark_dead_jobs_as_notified (force)
 #endif
 
   if (js.c_childmax < 0)
+#if defined (USE_FIXEDJSMAX_NUMBER)
+js.c_childmax = USE_FIXEDJSMAX_NUMBER;
+#else
 js.c_childmax = getmaxchild ();
   if (js.c_childmax < 0)
 js.c_childmax = DEFAULT_CHILD_MAX;
+#endif
 
   /* Don't do anything if the number of dead processes is less than CHILD_MAX
  and we're not forcing a cleanup. */
-- 
1.7.11.4

Re: AIX and Interix also do early PID recycling.

[Roman Rakus]

On 08/29/2012 04:06 PM, Michael Haubenwallner wrote:

On 08/28/2012 09:21 AM, Roman Rakus wrote:

On 08/01/2012 03:13 PM, Chet Ramey wrote:

On 7/30/12 10:41 AM, Roman Rakus wrote:


Hmm... I don't know much about boundaries of maximum number of user
processes. But anyway - do you think that (re)changing js.c_childmax (when
`ulimit -u' is changed) is not good?

Maybe it's ok up to some fixed upper bound.  But if you're going to have
that fixed upper bound, why not just use it as the number of job exit
statuses to remember all the time?


I prepared a patch which add configure option to enable and set the number of 
job exit statuses to remember.

Why not simply use the static CHILD_MAX value instead?
Feels like this is what the spec means - and conforming kernels do not 
guarantee for more
than that anyway, counting synchronous, asynchronous and substituted commands 
together.

However, Linux has stopped defining CHILD_MAX (not so) recently (value was 999),
so _POSIX_CHILD_MAX (25 is current value, 6 is old value) would feel correct 
then...

Anyway, now I do understand why people use pipes instead to get the child's 
exitstatus:
http://thread.gmane.org/gmane.linux.gentoo.portage.devel/3446/focus=3451

/haubi/
Well, you are right, POSIX requires to remember only CHILD_MAX number. 
But, as you wrote, CHILD_MAX is not defined any more on Linux systems.
From my point of view the problem is only if the limit is set to 
unlimited. How many values should bash remember? _POSIX_CHILD_MAX?


RR

Undocumented behaviour - parameter expansion ${par-word}

[Roman Rakus]

Hi,
Petr, adding to cc: list, found behaviour not documented, neither in man 
page nor bash ref manual:
${par-word} will do expansion of par, and if the par is unset it is 
substituted by word. It is different from ${par:-word}, where word is 
used when par is unset or null.


Is it undocumented and deprecated, like $[]? Or just undocumented?

RR

Re: Undocumented behaviour - parameter expansion ${par-word}

[Roman Rakus]

On 09/04/2012 01:19 PM, Clark WANG wrote:

On Tue, Sep 4, 2012 at 7:13 PM, Roman Rakus  wrote:


Hi,
Petr, adding to cc: list, found behaviour not documented, neither in man
page nor bash ref manual:
${par-word} will do expansion of par, and if the par is unset it is
substituted by word. It is different from ${par:-word}, where word is used
when par is unset or null.

Is it undocumented and deprecated, like $[]? Or just undocumented?


 From man page:

When  not  performing  substring  expansion, using the forms
documented
below, bash tests for a parameter that is unset or null.  Omitting
the
colon results in a test only for a parameter that is unset.



RR


Thanks you and Eric for answers. I should read more carefully, sorry for 
noise.


RR

Unused bash long option --debug

[Roman Rakus]

debug long option is not used, however it is declared. Is it for some 
reason? Backward compatibility?
It is a bit misleading, because bash --help shows --debug as a possible 
option.


RR

Bash long option --protected

[Roman Rakus]

'protected' long option has effect only when WORDEXP_OPTION is enabled, so this 
patch remove that option when WORDEXP_OPTION is not enabled.
The following patch should clearly apply to master branch.

[PATCH] Enable protected long option only if WORDEXP_OPTION is enabled

[Roman Rakus]

Signed-off-by: Roman Rakus 
---
 shell.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/shell.c b/shell.c
index 9e74f3b..87f740a 100644
--- a/shell.c
+++ b/shell.c
@@ -248,7 +248,9 @@ static const struct {
   { "noprofile", Int, &no_profile, (char **)0x0 },
   { "norc", Int, &no_rc, (char **)0x0 },
   { "posix", Int, &posixly_correct, (char **)0x0 },
+#if defined (WORDEXP_OPTION)
   { "protected", Int, &protected_mode, (char **)0x0 },
+#endif
   { "rcfile", Charp, (int *)0x0, &bashrc_file },
 #if defined (RESTRICTED_SHELL)
   { "restricted", Int, &restricted, (char **)0x0 },
-- 
1.7.6.5

Re: Should ~$user be tilde expanded?

[Roman Rakus]

On 10/25/2012 04:07 PM, Clark WANG wrote:

See following example:

$ cat foo.sh
u=root
echo ~$u
$ bash foo.sh  # bash 4.2.37
~root
$ ksh foo.sh  # ksh 93u+ 2012-08-01
/root
$

Anyone can explain/confirm what should be the correct behavior?

-Clark

http://www.gnu.org/software/bash/manual/bashref.html#Shell-Expansions

quoting:
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.


And posix is saying:
The order of word expansion shall be as follows:

1. Tilde expansion (see Section 2.6.1), parameter expansion (see Section 
2.6.2, on page 2306),
  command substitution (see Section 2.6.3, on page 2309), and 
arithmetic expansion (see

 Section 2.6.4, on page 2299).


So I will say, bash is doing it right. Firstly tries tilde expansion and 
then parameter expansion.


RR

Re: RFE: printf '%(fmt)T' prints current time by default

[Roman Rakus]

On 11/14/2012 04:00 AM, Clark WANG wrote:

In ksh:

$ printf '%(%F %T)T\n'
2012-11-14 10:57:26
$

In bash:

$ printf '%(%F %T)T\n'
1970-01-01 08:00:00
$

I think the ksh behavior is makes more sense so can we use the current time
as the default?

-Clark

For it there is -1 special parameter for printf:

$ printf '%(%F %T)T\n' -1
2012-11-14 12:54:56

RR

Re: How to initialize a read-only, global, associative array in Bash?

[Roman Rakus]

On 11/26/2012 10:45 PM, Tim Friske wrote:

Hi folks,

Hi


I execute the following code in Bash version "GNU bash, Version
4.2.39(1)-release (x86_64-redhat-linux-gnu)":

function foobar {
   declare -rgA FOOBAR=([foo]=bar)
}
foobar
declare -p FOOBAR
# Output: declare -Ar FOOBAR='()'

I think there should be also -g but it is not


Why doesn't Bash initialize FOOBAR with ([foo]=bar) according to
declare -p? The same declaration works outside of a function, e.g.

declare -rgA FOOBAR=([foo]=bar)
declare -p FOOBAR
# Output: declare -Ar FOOBAR='([foo]="bar" )'

Similarly the following code but without FOOBAR being read-only works:

function foobar {
   declare -gA FOOBAR
   FOOBAR=([foo]=bar)
}
foobar
declare -p FOOBAR
# Output: declare -A FOOBAR='([foo]="bar" )'

Is this a bug or feature?

Cheers,
Tim

BTW: I couldn't find a "bashbug" RPM package in the Fedora 17
repositories; that's why I wrote this formless mail. Sorry for that.

/usr/bin/bashbug-64
I will try to add symlink or something. Thanks

--
`°<
C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC

[PATCH] Use size_t for variable list size and length

[Roman Rakus]

see 
https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow

Signed-off-by: Roman Rakus 
---
 variables.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/variables.h b/variables.h
index 84e92bb..7a6bd6f 100644
--- a/variables.h
+++ b/variables.h
@@ -95,8 +95,8 @@ typedef struct variable {
 
 typedef struct _vlist {
   SHELL_VAR **list;
-  int list_size;   /* allocated size */
-  int list_len;/* current number of entries */
+  size_t list_size;/* allocated size */
+  size_t list_len; /* current number of entries */
 } VARLIST;
 
 /* The various attributes that a given variable can have. */
-- 
1.7.11.7

Re: [PATCH] Use size_t for variable list size and length

[Roman Rakus]

On 12/01/2012 02:47 AM, Chet Ramey wrote:

On 11/29/12 5:07 AM, Roman Rakus wrote:

see 
https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow

I've actually read this.

I'm skeptical that this change has any practical effect at all.  I'd like
to see a case where the use of ints in this struct causes overflow, even
on a 32-bit machine.

Chet

Hi chet,
you're right, it has no practical effect - rather esthetical. If I'm 
calculating it well the case should contain more than 536870912 
variables (2^32/8).
I have no access to 32-bit machine right now, but I can try to run 
following script:


for ((i=0; i<$((2**32/8 +1)); i++))
do
  eval "a$i=a$i"
done

RR

Re: Some globstar patterns produce duplicate entries and a null filename

[Roman Rakus]

On 12/01/2012 04:41 PM, Ulf Magnusson wrote:

GNU bash, version 4.2.24(1)-release (i686-pc-linux-gnu)

Take the following example, assumed to be run in an empty directory:

$ mkdir a
$ echo **
a
$ echo **/**
  a a
$ echo **/**/**
  a a a

I would expect the result to be just 'a' in all cases.

You also get back a null filename, as shown by

$ for f in **/**/**; do echo "'$f'"; done
''
'a'
'a'
'a'

/Ulf

I can't reproduce it on my Fedora with bash 4.2.10 nor 4.2.39. Tried 
turn on and off extglob shell option.
Can you please resend your report with `bashbug' script? Or at least say 
which linux distribution you are using?


RR

Re: Some globstar patterns produce duplicate entries and a null filename

[Roman Rakus]

On 12/02/2012 05:57 PM, Ulf Magnusson wrote:

Oh - you need to enable 'globstar', not 'extglob'.:)

/Ulf

Yes, you're right.
Bash incorrectly expands to empty string and duplicated results.

RR

Re: Some globstar patterns produce duplicate entries and a null filename

[Roman Rakus]

On 12/05/2012 04:07 AM, Chet Ramey wrote:

On 12/1/12 10:41 AM, Ulf Magnusson wrote:

GNU bash, version 4.2.24(1)-release (i686-pc-linux-gnu)

Take the following example, assumed to be run in an empty directory:

$ mkdir a
$ echo **
a
$ echo **/**
  a a
$ echo **/**/**
  a a a

I would expect the result to be just 'a' in all cases.

You also get back a null filename, as shown by

$ for f in **/**/**; do echo "'$f'"; done
''
'a'
'a'
'a'


Thanks for the report.  This is definitely a problem.  It will be fixed
in the next version of bash, and may be released as a future patch.  I've
attached a patch for you to test; it fixes the problem for me without
introducing any new errors.

Chet


Works well when used up to 2 levels of ** - ** and **/** is fixed.
However still produce duplicates, when used more levels - **/**/**. Also 
produce duplicates for **/a/** form.


Attaching script which I use for testing.

RR


test.sh
Description: application/shellscript

Re: Some globstar patterns produce duplicate entries and a null filename

[Roman Rakus]

On 12/10/2012 11:29 PM, Chet Ramey wrote:

On 12/5/12 3:17 AM, Roman Rakus wrote:


Works well when used up to 2 levels of ** - ** and **/** is fixed.
However still produce duplicates, when used more levels - **/**/**. Also
produce duplicates for **/a/** form.


The next version will treat any sequence of **/** the same as **, so those
duplicates will be suppressed.

I'm going to argue that some duplicates are going to be expected when you
have patterns like **/a/** that can match the same directory name using
two different "paths," if you will.  Other shells that implement **, such
as ksh93, agree.  Imperfect, but there's not a good solution.

Chet



Interesting. So it is up to script writer to delete duplicates. Will you 
be interested in patch which will clear duplicates? Let's say it will be 
some function run after expansion. And it will be optionally turned on. 
I guess it will not have any higher glob execution time impact.


RR

Re: tab completion with variable expansion broken

[Roman Rakus]

On 12/11/2012 06:03 PM, njhwang wrote:

Thanks, this is exactly what I needed to fix the issue on my end as well.

I'm curious if anyone who patched bash in this manner started seeing a weird
issue with long commands in the terminal? After building bash-4.2.29, long
commands would no longer break into multiple lines in gnome-terminal, and
would start overwriting the first line with a '>' character at the
beginning. After a lot of searching and attempts to fix it, I ended up just
using byobu (a terminal emulator using screen) to make the new line issue go
away. Any ideas what the root cause might be?



--
View this message in context: 
http://gnu-bash.2382.n7.nabble.com/tab-completion-with-variable-expansion-broken-tp10798p11122.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.

I would check PS1 especially if you have correctly escaped non-printing 
characters.


RR

Re: No such file or directory

[Roman Rakus]

On 01/02/2013 02:25 AM, Mike Frysinger wrote:

On Tuesday 01 January 2013 15:10:00 Chet Ramey wrote:

On 1/1/13 2:49 PM, Aharon Robbins wrote:

Michael Williamson wrote:

I have a complaint. Apparently, when unknowingly attempting to run a
32-bit executable file on a 64-bit computer, bash gives the error
message "No such file or directory". That error message is baffling and
frustratingly unhelpful. Is it possible for bash to provide a better
error message in this case?


It's not Bash. That is the error returned from the OS in errno when
it tries to do an exec(2) of the file.  Bash merely translates the
error into words.


FWIW, the file in question that's not found is either the 32-bit version
of the loader or one of the required 32-bit libraries, not the binary
itself.


it's the ldso missing.  if a lib was missing, the ldso would spit out a useful
message telling you exactly which lib could not be found.  at least, that's
the standard Linux (glibc/uclibc/etc...) behavior.

$ ./a.out: error while loading shared libraries: libfoo.so: cannot open shared
object file: No such file or directory
-mike

The patch stated in 
http://lists.gnu.org/archive/html/bug-bash/2002-03/msg00052.html is 
applied in Fedora.

Chet, is it possible to apply it to source?

RR

Re: No such file or directory

[Roman Rakus]

On 01/02/2013 03:31 PM, Eric Blake wrote:

On 01/02/2013 07:28 AM, Michael Williamson wrote:

Hi Aharon,

Thanks for your explanation. Now I have another question.
Why is the error message for ENOENT simply
"No such file or directory", when the man page for execve
has this complete description:
"The file filename or a script or ELF interpreter does not exist,
  or a shared library needed for file  or  interpreter  cannot  be
  found."?


Because that's what strerror() in your libc reports.  It's not bash's
fault if libc produces a shorter message (correct in the common case)
than what the man pages says is possible in the more comprehensive case.


I think the best would be if kernel provides more informations.

RR

[PATCH] Fix several missing close() calls.

[Roman Rakus]

There are missing calls of close() leading to resource leak (fd leak).
Simple reproducer:
. /
and /proc/$$/fd contain one open fd for each above call

Signed-off-by: Roman Rakus 
---
 builtins/evalfile.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/builtins/evalfile.c b/builtins/evalfile.c
index 60f89d1..d30bd96 100644
--- a/builtins/evalfile.c
+++ b/builtins/evalfile.c
@@ -133,11 +133,13 @@ file_error_and_exit:
   if (S_ISDIR (finfo.st_mode))
 {
   (*errfunc) (_("%s: is a directory"), filename);
+  close(fd);
   return ((flags & FEVAL_BUILTIN) ? EXECUTION_FAILURE : -1);
 }
   else if ((flags & FEVAL_REGFILE) && S_ISREG (finfo.st_mode) == 0)
 {
   (*errfunc) (_("%s: not a regular file"), filename);
+  close(fd);
   return ((flags & FEVAL_BUILTIN) ? EXECUTION_FAILURE : -1);
 }
 
@@ -146,6 +148,7 @@ file_error_and_exit:
   if (file_size != finfo.st_size || file_size + 1 < file_size)
 {
   (*errfunc) (_("%s: file is too large"), filename);
+  close(fd);
   return ((flags & FEVAL_BUILTIN) ? EXECUTION_FAILURE : -1);
 }  
 
-- 
1.7.11.7

Re: interrupted system call when using named pipes on FreeBSD

[Roman Rakus]

On 01/29/2013 10:59 PM, Chet Ramey wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/18/13 1:30 AM, Mike Frysinger wrote:

this is somewhat a continuation of this thread:
http://lists.gnu.org/archive/html/bug-bash/2008-10/msg00091.html

i've gotten more or less the same report in Gentoo:
http://bugs.gentoo.org/447810

the simple test case is:
$ cat test.sh
#!/bin/bash
while :; do
(:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)&
while read x ; do : ; done < <(echo foo)
done

execute `./test.sh` and we see failures pretty much all the time.


I did some looking around, and the script does result in open returning
- -1/EINTR, even if SIGCHLD is installed with SA_RESTART, on FreeBSD and
Mac OS X.  It doesn't happen on RHEL 5.  I may test Solaris 11 later.

I did find a reference to the Linux kernel patch that makes this work:

http://marc.info/?l=linux-kernel&m=134071285509470

Chet

- --
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEIRk8ACgkQu1hp8GTqdKvk/QCfQ+bl09en7Yonmj+0+Vqhjvlk
7ykAn00mDwdQT5hTD9L7z/GN+8NFMTzS
=wKJk
-END PGP SIGNATURE-


There is similar problem with ioctl() syscall in read.
Consider following script:
#!/bin/bash
( while :; do kill -CHLD $$ 2>&- || break; done ) &
while :; do
read -p 1 -t 0.01 -d ' '
done

On my Fedora it is reporting many
/tmp/test.sh: line 4: read: error setting terminal attributes: 
Interrupted system call
Hold down Enter key and when you are lucky you'll end up with SIGABRT. 
Definitely it's a bug in kernel, but I'm not sure if there is also 
something wrong in bash.


RR

Re: interrupted system call when using named pipes on FreeBSD

[Roman Rakus]

On 01/30/2013 10:06 AM, Roman Rakus wrote:

There is similar problem with ioctl() syscall in read.
Consider following script:
#!/bin/bash
( while :; do kill -CHLD $$ 2>&- || break; done ) &
while :; do
 read -p 1 -t 0.01 -d ' '
done

On my Fedora it is reporting many
/tmp/test.sh: line 4: read: error setting terminal attributes:
Interrupted system call
Hold down Enter key and when you are lucky you'll end up with SIGABRT.
Definitely it's a bug in kernel, but I'm not sure if there is also
something wrong in bash.

RR

reported, see http://marc.info/?l=linux-kernel&m=135948656610281

RR

Re: Should this be this way?

[Roman Rakus]

On 02/26/2013 02:03 AM, Linda Walsh wrote:

My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well.
Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash.

which is not always correct. Use type builtin.


I had the foll0wing script which acts differently based on
whether or not it has a #!/bin/bash at the top: (i.e., as it is
displayed below, it fails; one need remove the [] from the first
line for it to work.

#[!/bin/bash]

I think the line above will produce unspecified behavior.

while read fn;do
   base=${fn%.*}
   if [[ -e $base ]]; then
 if [[ $base -ot $fn ]]; then echo "compressed version ($fn) seems newer"
 elif [[ $base -nt $fn ]]; then echo "uncompressed version ($base)
seem newer"
 else echo "both versions ($base) are same age"
 fi
   else
 echo "No uncompressed version of $base exists"
   fi
done < <(find . -type f -name \*.[0-9].\*[zZ]\* )
-
The error:
./manscan.sh: line 12: syntax error near unexpected token `<'
./manscan.sh: line 12: `done < <(find . -type f -name \*.[0-9].\*[zZ]\* )'

Why would this script behave differently if the first line
exists or not?  (Putting the !shell in square brackets,
made it a comment, not an interpreter spec, thus the same
effect as if it wasn't there ('cept the line number of the error is 1
less if you don't have the line! ;-)).

So...is this correct behavior for some[inane POSIX] reason?
Seems a bit odd to me.

Is kernel or bash processing the shebang?

RR

autoconf 2.69?

[Roman Rakus]

Support for the ARM 64 bit CPU architecture (aarch64) was introduced in
autoconf 2.69.  bash uses an earlier version of
autoconf, preventing its being built.

Is there any plan to upgrade to version 2.69. Looking at devel branch it 
is using 2.68.


RR

Re: No such file or directory

[Roman Rakus]

On 01/02/2013 06:27 PM, Mike Frysinger wrote:

that ship has already sailed
Sorry for late response, but do you have some link or something? I would 
like to track it.


RR

Re: to - Bookmark file system locations in bash on POSIX-like systems

[Roman Rakus]

I think the much better would be to improve getopt command or getopts 
builtin.


RR

On 04/10/2013 03:35 PM, dnade@orange.com wrote:

Sorry to hack the thread, but I was wondering too if there was actually a 
place/list to announce such contributions.

I've recently developpedhttps://github.com/Anvil/bash-argsparse  (high level argument 
parsing library for bash) and wanted to submit it to the "bash community" for 
review, comments, and increase my own small user community.

Regards,

D

--
Damien Nadé
Astek Sud-Est pour France Télécom - FT/OF/OFA/DMGP/PORTAIL/DOP/DEV/EAQS
Sophia Antipolis - France / Tel : 04 97 46 28 74

Re: segfault on rl_completion_matches() interrupt

[Roman Rakus]

On 04/15/2013 01:08 AM, Raphaël Droz wrote:

Using both 4.2 and 4.3, I can reproduce a segfault on completion (though
not using gdb)

This can happen very consistently using a time-consuming completion like
the one for `man`, eg:
$ man g^C


Attached is the trace from a core-file using `man gpg-agent g^C`
with bash 4.3.


Side note: as more and more completions take time to finish (think ssh,
dpkg, ...), having ^G to interrupt the completion process and not having
to use ^C which discard the whole line could be useful.

From quick look I see missing memory allocation and probably dislocation.

RR