Graeberschaendung auf bundesdeutsche Anordnung

[adam]

Lese selbst:
http://www.die-kommenden.net/dk/zeitgeschichte/graeberschaendung.htm



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Dresden Bombing Is To Be Regretted Enormously

[adam]

Full Article:
http://service.spiegel.de/cache/international/0,1518,341239,00.html


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

mv to a non-existent path now renames instead of failing

[adam]

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_FORTIFY_SOURCE=2 
-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong 
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' 
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' 
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
uname output: Linux korath.teln.shikadi.net 4.5.0-1-drm-intel-nightly #1 SMP 
PREEMPT Sun Mar 13 10:42:04 AEST 2016 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu

Bash Version: 4.3
Patch Level: 42
Release Status: release

Description:
Moving a directory to a non-existent path will rename the directory 
instead
of reporting that the destination directory does not exist.

Repeat-By:
rmdir two 2> /dev/null
mkdir one
mv one two/

This should (and did in earlier versions) return an error, since the 
"two"
directory does not exist, so the "one" folder cannot be moved inside of 
it.
If the trailing slash was left off "two/", the command should (and does,
and always did) rename the folder.  However recently the command with 
the
trailing slash has started renaming the folder instead of returning an
error.

I often rely on the error result so that I don't have to check whether 
the
destination directory exists before performing the move operation, but 
now
the process will always succeed, silently becoming a rename operation
unpredictably.  I have already lost a handful of folders this way, only
realising later that they were renamed without warning when I did not
intend them to be renamed.

Disabling Job Control or Enabling Minimal Config Breaks Build

[Adam Pippin]

Bash Version: 4.2

Description:

I downloaded a fresh copy of bash 4.2 from the GNU project archives (
http://ftp.gnu.org/gnu/bash/bash-4.2.tar.gz), configured with:

./configure --disable-job-control --enable-minimal-config
--disable-readline

(Self-Serving Explanation: I'm attempting to debug another issue with this
system at the moment related to bash seemingly masking out the SIGWINCH
signal and not acknowledging terminal resizing.
http://serverfault.com/questions/452340 if anyone's feeling generous and
wishes to take a look.)

However, it seems both --disable-job-control and --enable-minimal-config
break the build.

Specifically, using --enable-minimal-config seems to disable aliases. This
causes an error in parse.y:

/Users/chet/src/bash/src/parse.y: In function 'shell_getc':
/Users/chet/src/bash/src/parse.y:2399: error: label 'pop_alias' used
but not defined
make: *** [y.tab.o] Error 1

Looking at parse.y, the problem seems pretty clear. The label `pop_alias'
is not defined if ALIAS is not defined. However, about 15 lines down there
is a `goto_popalias' statement with no such condition.

The issue with --disable-job-control seems like it may be similar, however
I did not take the time to look any further in to it.

execute_cmd.c: In function 'execute_pipeline':
execute_cmd.c:2205: error 'job_control' undeclared (first use in this
function)



Repeat-By:

* Download a copy of bash 4.2.
* Configure with either or both of '--disable-job-control' and
'--enable-minimal-config'.
* Attempt to build.

Replicated on Debian and Ubuntu. Unfortunately I don't have access to any
other family of OS at the moment to ensure this isn't related to that
somehow, however it doesn't seem like it would be.

bash 3.1 does not compile for ./configure --disable-readline

[Adam Buraczewski]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -O2 -march=pentium2
uname output: Linux localhost 2.6.14.1 #1 Thu Nov 10 20:41:24 CET 2005 i686 
unknown unknown GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 3.1
Patch Level: 0
Release Status: release

Description:

Bash 3.1 does not compile without readline support.  The problem can
be narrowed to file variables.c, routine sh_set_lines_and_columns,
which checks variable winsize_assignment, declared only when readline
support is enabled.  It looks as this check can be ommitted entirely,
when READLINE symbol is not defined.  This bug prevents also building
bash with "./configure --enable-minimal-config".

The exact error message generated by GCC is:

variables.c: In function `sh_set_lines_and_columns':
variables.c:864: error: `winsize_assignment' undeclared (first use in this 
function)

Repeat-By:

cd bash-3.1
./configure --disable-readline
make

Fix:

*** variables.c.origSun Nov 13 03:22:37 2005
--- variables.c Mon Dec 19 11:36:24 2005
***
*** 860,868 
--- 860,870 
  {
char val[INT_STRLEN_BOUND(int) + 1], *v;
  
+ #if defined (READLINE)
/* If we are currently assigning to LINES or COLUMNS, don't do anything. */
if (winsize_assignment)
  return;
+ #endif
  
v = inttostr (lines, val, sizeof (val));
bind_variable ("LINES", v, 0);



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

unable to capture return value using backticks and local

[Adam Monsen]

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include
-I./lib  -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables
uname output: Linux localhost.localdomain 2.6.17-1.2157_FC5 #1 Tue Jul
11 22:55:46 EDT 2006 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu

Bash Version: 3.1
Patch Level: 7
Release Status: release

Description:
   When a variable is declared local and the assigned value is
gathered from
a command enclosed in backticks, it is not possible to retrieve the return value
of the function within the backticks. Is this expected behavior?

Repeat-By:
   The following code snippet describes the issue at hand:

TICKED=`false`
echo RV: $?
# prints "RV: 1"

foo()
{
   local TICKED=`false`
   echo RV: $?
}

foo
# prints "RV: 0", but I would expect "RV: 1"


--
Adam Monsen


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: unable to capture return value using backticks and local

[Adam Monsen]

On 8/8/06, Chet Ramey <[EMAIL PROTECTED]> wrote:
[...]

It is expected and documented.  `local' is a builtin command that returns
a 0 status if the assignment is performed.

[...]

Understood, thanks Chet.

Also, thank you Paul for the workaround.

I was incorrectly interpreting 'local' to be a modifier rather than a
separate builtin.

--
Adam Monsen


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Bad tokenisation inside backticks

[Adam Sampson]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/opt/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -O2
uname output: Linux cartman.at.offog.org 2.6.18-rt5-GS #1 SMP PREEMPT Mon Oct 2 
14:56:34 BST 2006 i686 GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 3.2
Patch Level: 0
Release Status: release

Description:
bash 3.2.0 appears to handle hashes inside strings inside backticks in
an unexpected way; this wasn't the case with previous versions as far
as I can tell.

Specifically, one of the scripts in the ncurses distribution does this:

TABSIZE=`grep -v '^[ #]' $CAPS | grep -v "^$" | grep -v "^capalias"| 
grep -v "^infoalias" | wc -l`

which causes bash 3.2.0 to fail with:

work/ncurses-5.6/include/MKhashsize.sh: line 38: unexpected EOF while 
looking for matching ``'

Repeat-By:
Do this at the bash prompt:

x=`echo " #"`

With bash 3.1.17 and 3.1.0, this works as expected; x gets the value " 
#".
With bash 3.2.0, you get the ">" prompt; doing it in a script reveals
that bash is looking for a matching backtick.



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Tab completion of commands in directories with spaces adds extra backslashes.

[Adam Buchbinder]

Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -D$
uname output: Linux adam-linux 2.6.28-15-generic #49-Ubuntu SMP Tue Aug
18 18:40:08 UTC 2009 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu

Bash Version: 3.2
Patch Level: 48
Release Status: release

Description:
When tab-completing the name of a command, if that command is
inside a directory with spaces in its name, the tab completion
will add extra backslashes.

Repeat-By:
$ mkdir ~/'x y'/'z w'
$ ~/x

After this, the command line will look like this:
$ ~/x\\\ y/z\ w
It should look like this:
$ ~/x\ y/z\ w

bash problems with tru64 4.0f

[adam . scheblein]

Configuration Information [Automatically generated, do not change]:
Machine: alphaev67
OS: osf4.0f
Compiler: cc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='alphaev67' 
-DCONF_OSTYPE='osf4.0f' -DCONF_MACHTYPE='alphaev67-dec-osf4.0f' 
-DCONF_VENDOR='dec' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' 
-DSHELL  -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib -I./lib/intl 
-I/home/adam/bash-3.0/lib/intl  -g
uname output: OSF1 libus.csd.mu.edu V4.0 1229 alpha
Machine Type: alphaev67-dec-osf4.0f

Bash Version: 3.0
Patch Level: 0
Release Status: release

Description:
every time i try to run bash i get the error "Memory Fault" and the 
system stops letting me use my ssh window.

Repeat-By:
compile on an older ds20e alphaserver running tru64 4.0f and run bash


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

problem with bash on tru64 4.0f

[adam . scheblein]

Configuration Information [Automatically generated, do not change]:
Machine: alphaev67
OS: osf4.0f
Compiler: cc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='alphaev67' 
-DCONF_OSTYPE='osf4.0f' -DCONF_MACHTYPE='alphaev67-dec-osf4.0f' 
-DCONF_VENDOR='dec' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' 
-DSHELL  -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib -I./lib/intl 
-I/home/adam/bash-3.0/lib/intl  -g
uname output: OSF1 libus.csd.mu.edu V4.0 1229 alpha
Machine Type: alphaev67-dec-osf4.0f

Bash Version: 3.0
Patch Level: 16
Release Status: release

Description:
After trying to troubleshoot an earlier Memory Fault problem with bash, 
i attempted to patch to the most current patch level which did not fix the 
problem.

Repeat-By:
install, patch, use on alpha ds20e running tru64 4.0f


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Declared Var Dynamic Initialization = No Return Code Back?

[Adam Danischewski]

$>declare MYSTERY_CMD=$(which mystery) && echo "All set." || echo "Adding
to missing array ... "
All set.

$>MYSTERY2_CMD=$(which mystery2) && echo "All set." || echo "Adding to
missing array ... "
Adding to missing array ...

Declaring a variable doesn't seem risky enough to eat up the return code.
Is there a reason for this? I doubt that it would break anything to change.
It's a lot more intuitive and syntactically streamlined to check for
missing packages/software at the initial declaration as a sanity check.

[Patch] potentially uninitialized variable in rl_generic_bind

[Adam Richter]

cppcheck noticed that, in the file lib/readline/bind.c, the function
rl_generic_bind contains a loop that declares a variable named ic in
the loop body, and relies on that variable being initialized with its
value from the previous iteration (in the line "prevkey = ic;"), which
is not something that the compiler guarantees.  This patch lifts the
declaration of ic outside the loop to ensure that its value is
preserved across those iterations.

The file produced by running "strip" on the resulting bind.o file is
unchanged by this patch on the x86_64 and i686 configurations that I
tried.

I have not signed an FSF copyright assignment, but I hereby release my
copyright interest in this trivial change to the public domain.  I
hope that suffices, but please let me know if that is not the case.

Thanks in advance for considering this patch submission.

Adam
diff --git a/lib/readline/bind.c b/lib/readline/bind.c
index 57ae10f..f69243d 100644
--- a/lib/readline/bind.c
+++ b/lib/readline/bind.c
@@ -356,6 +356,7 @@ rl_generic_bind (int type, const char *keyseq, char *data, Keymap map)
   register int i;
   KEYMAP_ENTRY k;
   Keymap prevmap;  
+  int ic;
 
   k.function = 0;
 
@@ -385,7 +386,6 @@ rl_generic_bind (int type, const char *keyseq, char *data, Keymap map)
   for (i = 0; i < keys_len; i++)
 {
   unsigned char uc = keys[i];
-  int ic;
 
   if (i > 0)
 	prevkey = ic;

[Patch] Remove unnecessary check in mkdir_builtin

[Adam Richter]

This second trivial patch fixes another cppcheck complaint.  Don't
worry.  I'm not am not submitting a flood of rivial patches right now.
I am only submitting these two right now, and I split them in two only
because they are so unrelated to each other.

In the pristine ftp.gnu.org version of bash-5.0, the file
examples/loadables/mkdir.c contains the function mkdir_builtin, which
has a multi-branch "if" statement, which tests a condition that was
already tested at the beginning of the "if" statement and does not
provide an unconditional "else" statement at the end.  This lead
cppcheck to wonder if a variable set in each of these branches could
possibly be uninitialized afterwards.  This patch deletes the
duplicative test, which at least should make any real bug in the
future that cppcheck may flag a little more apparent.

On the x86_64 and i686 configurations that I tried, the resulting
stripped mkdir.o file was the same with and without this change.

I hereby release any copyright interest I may have in this trivial
patch into the public domain.

Adam
diff --git a/examples/loadables/mkdir.c b/examples/loadables/mkdir.c
index b381119..8133cdb 100644
--- a/examples/loadables/mkdir.c
+++ b/examples/loadables/mkdir.c
@@ -93,7 +93,7 @@ mkdir_builtin (list)
 	  return (EXECUTION_FAILURE);
 	}
 }
-  else if (mode)
+  else
 {
   /* initial bits are a=rwx; the mode argument modifies them */
   omode = parse_symbolic_mode (mode, S_IRWXU | S_IRWXG | S_IRWXO);

ARGV[@] Not Always Populated

[Adam Danischewski]

*Configuration Information [Automatically generated, do not
change]:Machine: x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/bash-LQgi2O/bash-5.0=. -f$uname output: Linux
amdubuntu 5.0.0-29-generic #31-Ubuntu SMP Thu Sep 12 13:05$Machine Type:
x86_64-pc-linux-gnuBash Version: 5.0Patch Level: 3Release Status: release*

A description of the bug behaviour.
If you don't access the ARGV array before you drop into a function, ARGV is
not populated.
E.g. If the script below is named test.bsh
If I run:
$> test.bsh arg1 arg1val arg2 arg2val arg3 arg3val
*I expect the following output: *
inside the options handler with i = 5, BASH_ARGV[5] is arg1, BASH_ARGV[] is
arg3val
inside the options handler with i = 4, BASH_ARGV[4] is arg1val, BASH_ARGV[]
is arg3val
inside the options handler with i = 3, BASH_ARGV[3] is arg2, BASH_ARGV[] is
arg3val
inside the options handler with i = 2, BASH_ARGV[2] is arg2val, BASH_ARGV[]
is arg3val
inside the options handler with i = 1, BASH_ARGV[1] is arg3, BASH_ARGV[] is
arg3val
inside the options handler with i = 0, BASH_ARGV[0] is arg3val, BASH_ARGV[]
is arg3val
Instead nothing is printed.
If you uncomment the echo at the top of the script then the printing is as
expected.
I realize the Bash Documentation states:
   BASH_ARGV
  An  array variable containing all of the parameters in the
current bash
  execution call stack.  The final parameter of the last
subroutine  call
  is  at the top of the stack; the first parameter of the
initial call is
  at the bottom.  When a subroutine is executed, the parameters
 supplied
  are  pushed  onto BASH_ARGV.  The shell sets BASH_ARGV only
when in ex‐
  tended debugging mode (see the description of the  extdebug
 option  to
  the shopt builtin below).  Setting extdebug after the shell
has started
  to execute a script, or
*referencing this variable when extdebug is  not  set, may
result in inconsistent values.*
Many people are using BASH_ARGV:
e.g.
https://stackoverflow.com/questions/2740906/how-to-access-command-line-arguments-of-the-caller-inside-a-function
If it's not too much trouble I think a lot of people would be glad if you
could make this work in a standardized way.

A short script or ‘recipe’ which exercises the bug and may be used to
reproduce it.

> #!/bin/bash
> ## If you uncomment the next line, command line args are printed;
> #echo "inside top version_ctl, args:${BASH_ARGV[@]}, #
> args:${#BASH_ARGV[@]} "
> function process_options() {
> local -i i=0
> local CURVAL=""
> local NEXTVAL=""
> for((i=$((${#BASH_ARGV[@]}-1));i>=0;i--)); do
>  CURVAL=${BASH_ARGV[${i}]}
>  NEXTVAL=${BASH_ARGV[$((${i}-1))]}
>  echo "inside the options handler with i = $i, BASH_ARGV[${i}] is
> ${BASH_ARGV[${i}]}, BASH_ARGV[${next_arg}] is ${BASH_ARGV[${next_arg}]} "
> done
> return ${RETURN_CODE}
> }
>
> process_options
> exit 0

Error expanding variable containing a directory name

[Lutz Adam]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. 
-fstack-protector-strong -Wformat -Werror=format-
uname output: Linux fractal 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 
00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.0
Patch Level: 17
Release Status: release

Description:
   The content of $ML is "/media/lad".  There's a directory 
/media/lad/p24. Typing the command

            ls $ML/p24
   a backslash is put befor "$" and the line looks like:
            ls \$ML/p24/
   Typing the ENTER key shows:
            ls: cannot access '$ML/p24/': No such file or directory.

Repeat-By:
    Create a variable containing a directory name. Put a 
subdirectory there under.
        Type a "$" and the variable followed by a slash, the name of 
the subdirectora and the TAB-key.



The OS is Linux Mint 20

Shell does not recognize umlaut in URL

[Lutz Adam]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. 
-fstack-protector-strong -Wformat -Werror=format-
uname output: Linux fractal 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 
00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.0
Patch Level: 17
Release Status: release

Description:
   If a URL on the command line or in a file contains an umlaut as in
        https://dict.leo.org/franz*ö*sisch-deutsch
        the shell stops recognising the URL after the umlaut "ö". Only 
the part
   "https://dict.leo.org/franz*ö*"; is underlined and used in a call 
to a browser.**


Repeat-By:
    Put the above URL on the command line.
        1.   Hover over the ULR. Only the left part is underlined.
        2.   Press and hold CTRL, then left-click the URL: the URL is 
opened in a browser,

          but only the left part appears in the address field.

The OS is Linux Mint 20

Build fails with Xcode 12

[Adam Stewart]

code.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:70:30:
 note: variable 'sys_siglist' declared const here
extern __const char *__const sys_siglist[NSIG];
~^
siglist.c:75:24: error: cannot assign to variable 'sys_siglist' with 
const-qualified type 'const char *const [32]'
  sys_siglist[SIGABRT] = _("ABORT instruction");
   ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:70:30:
 note: variable 'sys_siglist' declared const here
extern __const char *__const sys_siglist[NSIG];
~^
siglist.c:79:23: error: cannot assign to variable 'sys_siglist' with 
const-qualified type 'const char *const [32]'
  sys_siglist[SIGEMT] = _("EMT instruction");
  ~~~ ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:70:30:
 note: variable 'sys_siglist' declared const here
extern __const char *__const sys_siglist[NSIG];
~^
siglist.c:83:23: error: cannot assign to variable 'sys_siglist' with 
const-qualified type 'const char *const [32]'
  sys_siglist[SIGFPE] = _("Floating point exception");
  ~~~ ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:70:30:
 note: variable 'sys_siglist' declared const here
extern __const char *__const sys_siglist[NSIG];
~^
siglist.c:87:24: error: cannot assign to variable 'sys_siglist' with 
const-qualified type 'const char *const [32]'
  sys_siglist[SIGKILL] = _("Killed");
   ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:70:30:
 note: variable 'sys_siglist' declared const here
extern __const char *__const sys_siglist[NSIG];
~^
siglist.c:91:23: error: cannot assign to variable 'sys_siglist' with 
const-qualified type 'const char *const [32]'
  sys_siglist[SIGBUS] = _("Bus error");
  ~~~ ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:70:30:
 note: variable 'sys_siglist' declared const here
extern __const char *__const sys_siglist[NSIG];
~^
siglist.c:95:24: error: cannot assign to variable 'sys_siglist' with 
const-qualified type 'const char *const [32]'
  sys_siglist[SIGSEGV] = _("Segmentation fault");
   ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:70:30:
 note: variable 'sys_siglist' declared const here
extern __const char *__const sys_siglist[NSIG];
~^
siglist.c:99:23: error: cannot assign to variable 'sys_siglist' with 
const-qualified type 'const char *const [32]'
  sys_siglist[SIGSYS] = _("Bad system call");
  ~~~ ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:70:30:
 note: variable 'sys_siglist' declared const here
extern __const char *__const sys_siglist[NSIG];
~^
siglist.c:103:24: error: cannot assign to variable 'sys_siglist' with 
const-qualified type 'const char *const [32]'
  sys_siglist[SIGPIPE] = _("Broken pipe");
   ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:70:30:
 note: variable 'sys_siglist' declared const here
extern __const char *__const sys_siglist[NSIG];
~^
siglist.c:107:24: error: cannot assign to variable 'sys_siglist' with 
const-qualified type 'const char *const [32]'
  sys_siglist[SIGALRM] = _("Alarm clock");
   ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:70:30:
 note: variable 'sys_siglist' declared const here
extern __const char *__const sys_siglist[NSIG];
~^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make: *** [siglist.o] Error 1


I can share the full build log if you need it.

Adam

Re: Build fails with Xcode 12

[Adam Stewart]

printf.c:1725:1: error: definition of builtin function 
'__builtin___snprintf_chk'
snprintf(char *string, size_t length, const char * format, ...)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:57:3:
 note: expanded from macro 'snprintf'
  __builtin___snprintf_chk (str, len, 0, __darwin_obsz(str), __VA_ARGS__)
  ^
snprintf.c:1738:21: error: use of undeclared identifier 'format'
  SH_VA_START(args, format);
^
snprintf.c:1742:37: error: use of undeclared identifier 'format'
  init_data (&data, string, length, format, PFM_SN);
^
snprintf.c:1743:53: error: use of undeclared identifier 'format'
  rval = vsnprintf_internal (&data, string, length, format, args);
^
14 errors generated.
make[1]: *** [snprintf.o] Error 1
make: *** [lib/sh/libsh.a] Error 1
make: *** Waiting for unfinished jobs


Do you have a patch for this as well?

Adam

Re: Build fails with Xcode 12

[Adam Stewart]

Thanks Chet,

That patch did the trick! All tests pass now. Thanks again for your help!

P.S. I'm going to add this patch to the Spack package manager. Would you or 
anyone else be interested in "maintaining" Spack's bash build recipe? You don't 
have to be a Spack expert, it just gives us someone to ping when users report 
build errors or submit PRs to modify the recipe. If so, just send me your 
GitHub handle(s).

Adam

Patch bash43-028 doesn't apply

[Adam Sampson]

Hi bug-bash,

The patch bash43-028 on ftp.gnu.org doesn't apply. It has a load of
hunks with yacc filenames in:

! #line 324 "/usr/src/local/bash/bash-4.3-patched/parse.y"

But the filename in the upstream source is different, so that doesn't
match.

Thanks,

-- 
Adam Sampson  <http://offog.org/>

When exactly it is possible to modify BASH_LINENO variable?

[Adam Ryczkowski]

I am trying to write a function that logs execution of the *next* line. 
The usage would be:


#/bin/bash
log=/tmp/mylog.log
var1="some variable"

log
echo "Unfortunately this line gets executed twice" | tee -a 
/tmp/temp/bla-bla.tmp


The problem is that I can't reliably get to modify `BASH_LINENO[0]`. I 
swear, that I used to have success in it, but now everytime I change its 
value (both inside or outside the function body) the assignment gets 
ignored. Is there any way to get the bash to skip execution of the next 
line?


The script goes along these lines:

function log()
{
case $- in *x*) USE_X="-x";; *) USE_X=;; esac
set +x
if [ -n "$log" ]; then
file=${BASH_SOURCE[1]##*/}
linenr=$((${BASH_LINENO[0]} + 1 ))
line=`sed "1,$((${linenr}-1)) d;${linenr} s/^ *//; q" $file`
if [ -f /tmp/tmp.txt ]; then
rm /tmp/tmp.txt
fi
echo "$line" > /tmp/tmp2.txt
BASH_LINENO[0]=$((${BASH_LINENO[0]}+1))  #EXECUTES FINE, BUT 
DOESN'T CHANGE THE CALL STACK

mymsg=`msg2`
exec 3>&1 4>&2 >>/tmp/tmp.txt 2>&1
set -x
source /tmp/tmp2.txt
exitstatus=$?
set +x
exec 1>&3 2>&4 4>&- 3>&-
#...
#Here goes part, that parses the /tmp/tmp.txt and appends stuff 
into $log

#...
fi
if [ -n "$USE_X" ]; then
set -x
fi
if [ "$exitstatus" -ne "0" ]; then
    exit $exitstatus
fi
}




This message is a crosspost from 
http://stackoverflow.com/questions/27259418/how-to-modify-call-stack-in-bash



Adam

[PATCH] document the -p invocation flag

[Adam Endrodi]

--- bash-4.2/doc/bash.1.orig2015-06-10 15:09:04.0 +0200
+++ bash-4.2/doc/bash.1 2015-06-10 15:19:55.0 +0200
@@ -117,6 +117,18 @@
 This option allows the positional parameters to be set
 when invoking an interactive shell.
 .TP
+.B \-p
+If the
+.B \-p
+is
+.B not
+present and the real and effective user or group IDs mismatch on startup,
+the effective user and group IDs are set to the real ones.  This behavior
+can be disabled with this flag, but see 
+.SM
+.B "INVOCATION"
+for notes about setuid invocation.
+.TP
 .B \-D
 A list of all double-quoted strings preceded by \fB$\fP
 is printed on the standard output.

-- 
QED

read Built-in Parameter Behavior -- Null Byte Delimiter

[Adam Danischewski]

It seems the parameter for the delimiter for the read built-in behaves
differently for the NULL case, and it is a very useful case. I found this
after a difficult to track down bug appeared in some of  my code, so I
thought I would pass it on to you.

If it is expected behavior I didn't see it in the documents. Most other
options seem to follow the getopts model and allow for no space for
parameter arguments.

It seems to work for the read built-in yet not for NULL read -d''.

E.g.
$> touch file_{1..40..3}.txt
$> while IFS= read -r -d'.' a; do echo "got $a"; done < <(find . -type f
-print0)
 *  has the same results as *
$> while IFS= read -r -d '.' a; do echo "got $a"; done < <(find . -type f
-print0)
got
got /file_40
got txt
got /file_37
...
got txt
got /file_1

Yet if we look for the null byte:
$> while IFS= read -r -d'' a; do echo "got $a"; done < <(find . -type f
-print0)
 *  returns nothing *
$> while IFS= read -r -d '' a; do echo "got $a"; done < <(find . -type f
-print0)
   *returns the expected results*
got ./file_40.txt
got ./file_37.txt
got ./file_34.txt
...
got ./file_16.txt

Re: read Built-in Parameter Behavior -- Null Byte Delimiter

[Adam Danischewski]

> > Other shells must go out of their way to suppress it, then.
>
> Most of the other shells remove NUL bytes from `read's input.  They
> probably do this before checking the delimiter.


Bash also removes the single quotes before it hits read when the single
quotes are attached to the delimiter option (-d'').

I know its possible to not think of it as a bug, but it can cause very
difficult to find errors because the other behavior -- putting the quoted
argument next to the option -- works when the option value is not null -- a
null delimiter option for read is common and useful -- so I think it's
something worth addressing.

Perhaps it would be possible to put a filter on the Bash interpreter to
check for the case of empty single quotes next to an option and handle it
separately as special case?

*E.g.* my.bsh

#!/bin/bash
echo "$#"
while getopts d: OPTION "$@"; do
 case "$OPTION" in
   d)
 echo "the optarg is ${OPTARG##*=}, optind is ${OPTIND}"
 [[ -z "${OPTARG}" ]] && echo "Let's set the null byte as the delim."
;;
 esac
done
exit 0

$> ./my.bsh -d'' arg1  ## Incorrectly interprets arg1 as the option
argument.
2
the optarg is arg1, optind is 3

## If Bash instead would do something like this to preserve the presence of
the null argument I think it would alleviate a potential source of bugs:

$> eval $(echo "./my.bsh -d'' arg1" | sed "s/-d''/-d ''/g")
3
the optarg is , optind is 3
Let's set the null byte as the delim.

+AMD

Re: read Built-in Parameter Behavior -- Null Byte Delimiter

[Adam Danischewski]

Right, the programs don't see those empty strings because the shell is
stripping them when it parses the line. But for options, for the shell
parser to strip away the empty string presumes that the user made a mistake
and has needlessly/erroneously provided a useless empty string.

In the case for read -d'' very probably the user has attempted to supply
the null delimiter, but read quietly takes the next argument. I think it
makes sense to bump empty strings away from the option when they occur
after options in the Bash interpreter parsing of the commandline.
-d''  --> -d ''

On Tue, Jan 19, 2016 at 11:49 AM, Greg Wooledge  wrote:

> On Tue, Jan 19, 2016 at 11:39:07AM -0500, Adam Danischewski wrote:
> > Bash also removes the single quotes before it hits read when the single
> > quotes are attached to the delimiter option (-d'').
>
> And in EVERY OTHER COMMAND.  This is how quotes work.  This is utterly
> fundamental to bash and the entire Bourne shell syntax.
>
>   echo ""'a'''$''""''
>
> Is *exactly* the same as
>
>   echo a
>
> Echo has no way to know that you typed a and not "a" or a"" or 'a' or 
>

Bash $@ Parameter Variable Breaking Out of Strings

[Adam Danischewski]

I noticed an issue using the parameter built-in variable $@ breaking
out of contained strings when utilized in functions.

For example, consider the following bash script: m.bsh
#!/bin/bash
echo "$#"
while getopts d: OPTION "$@"; do
 case "$OPTION" in
   d)
 echo "the optarg is ${OPTARG##*=}, optind is ${OPTIND}"
 [[ -z "${OPTARG}" ]] && echo "Let's set the null byte as the delim."
;;
 esac
done
exit 0

$ alias t1='_() { var=$@; /tmp/m.bsh -d "clarify ${var}"; }; _'
$ t1 hi there
2
the optarg is clarify hi there, optind is 3
 ### Correctly considers the text as a single string argument
 containing a space.

$ alias t2='_() { /tmp/m.bsh -d "clarify $@"; }; _'
$ t2 hi there
3
the optarg is clarify hi, optind is 3
 ### Incorrectly breaks the argument array variable out as separate
 single string arguments.

I noticed another interesting occurrence as well, I'm not sure if they are
related, to variable names:

function update() {
local -i VAR=45
VAR+=-1
VAR+=$1
echo $VAR
}

$ VAR2=2
$ update VAR2
  47

$ VAR=3
$ update VAR
  88 ### !?

Re: Bash $@ Parameter Variable Breaking Out of Strings

[Adam Danischewski]

I hit send by accident, disregard the first part - I had the info page open
and didn't realize I had sent the email already, the "$*" is what I should
be using.

The second part is still of a mystery, again a quick typo where it states
VAR2=2, it should read VAR2=3 to obtain 47.

On Tue, Mar 22, 2016 at 10:47 AM, Adam Danischewski <
adam.danischew...@gmail.com> wrote:

> I noticed an issue using the parameter built-in variable $@ breaking
> out of contained strings when utilized in functions.
>
> For example, consider the following bash script: m.bsh
> #!/bin/bash
> echo "$#"
> while getopts d: OPTION "$@"; do
>  case "$OPTION" in
>d)
>  echo "the optarg is ${OPTARG##*=}, optind is ${OPTIND}"
>  [[ -z "${OPTARG}" ]] && echo "Let's set the null byte as the delim."
> ;;
>  esac
> done
> exit 0
>
> $ alias t1='_() { var=$@; /tmp/m.bsh -d "clarify ${var}"; }; _'
> $ t1 hi there
> 2
> the optarg is clarify hi there, optind is 3
>  ### Correctly considers the text as a single string argument
>  containing a space.
>
> $ alias t2='_() { /tmp/m.bsh -d "clarify $@"; }; _'
> $ t2 hi there
> 3
> the optarg is clarify hi, optind is 3
>  ### Incorrectly breaks the argument array variable out as separate
>  single string arguments.
>
> I noticed another interesting occurrence as well, I'm not sure if they are
> related, to variable names:
>
> function update() {
> local -i VAR=45
> VAR+=-1
> VAR+=$1
> echo $VAR
> }
>
> $ VAR2=2
> $ update VAR2
>   47
>
> $ VAR=3
> $ update VAR
>   88 ### !?
>
>
>

Re: Bash $@ Parameter Variable Breaking Out of Strings

[Adam Danischewski]

Thanks for the quick reply, I hit send by accident, the first part is clear
in the documentation.

On the second part, I still see a potential problem because Bash is
allowing for access to the internal local function variables.

E.g.
function update() {
local -i VAR=45
local -i TOPSECRET_NUMBER=50 ## No one can know about.
VAR+=${1}
echo $VAR
}

$ update 0
45
$ update TOPSECRET_NUMBER
95

## Successfully deduce that TOPSECRET_NUMBER is 50
## Instead could be CC_NUM, CCARD, SessionID, CrToken, etc.

On Tue, Mar 22, 2016 at 11:18 AM, Chet Ramey  wrote:

> On 3/22/16 10:47 AM, Adam Danischewski wrote:
> > I noticed an issue using the parameter built-in variable $@ breaking
> > out of contained strings when utilized in functions.
> >
> > For example, consider the following bash script: m.bsh
> > #!/bin/bash
> > echo "$#"
> > while getopts d: OPTION "$@"; do
> >  case "$OPTION" in
> >d)
> >  echo "the optarg is ${OPTARG##*=}, optind is ${OPTIND}"
> >  [[ -z "${OPTARG}" ]] && echo "Let's set the null byte as the delim."
> > ;;
> >  esac
> > done
> > exit 0
> >
> > $alias t1='_() { var=$@; /tmp/m.bsh -d "clarify ${var}"; }; _'
> > $t1 hi there
> > 2
> > the optarg is clarify hi there, optind is 3
> >  ### Correctly considers the text as a single string argument
> >  containing a space.
>
> The $@ is expanded in a context where word splitting is not performed.
> There has actually been a lot of discussion about this case on the
> Posix shell standardization mailing list.
>
> >
> > $alias t2='_() { /tmp/m.bsh -d "clarify $@"; }; _'
> > $ t2 hi there
> > 3
> > the optarg is clarify hi, optind is 3
> >  ### Incorrectly breaks the argument array variable out as separate
> >  single string arguments.
>
> I'm not sure why you think this is a problem.  When $@ occurs in double
> quotes, it expands to multiple words, one for each positional parameter,
> combined with the portions of the string before and after it.  "$@" always
> expands to multiple words if there are multiple positional parameters and
> word splitting is performed.
>
> > I noticed another interesting occurrence as well, I'm not sure if they
> are
> > related, to variable names:
> >
> > function update() {
> > local -i VAR=45
> > VAR+=-1
> > VAR+=$1
> > echo $VAR
> > }
> >
> > $ VAR2=2
> > $ update VAR2
> >   47
> >
> > $ VAR=3
> > $ update VAR
> >  88 ### !?
>
> There's no mystery here.  When a variable name is used in arithemtic
> evaluation context, its value is expanded as an expression.  Since VAR is
> an integer variable, the rhs of any assignment to it is considered an
> arithmetic expression and evaluated as such.
>
> So what you end up with is
>
> local -i VAR=45 # VAR = 45
> VAR+=-1 # VAR = 44, local var takes precedence
> VAR+=VAR# VAR += 44 --> VAR = 88, local var used
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>

[Documentation] -d returns true for symlink to directory

[Adam McKenna]

BASH Man page conditional expressions:

   -d file
  True if file exists and is a directory.

This is also stated at https://www.gnu.org/software/bash/manual/bashref.html

The operator also returns True if the file exists and is a symlink to a
directory

-bash-4.1$ file foo
foo: directory
-bash-4.1$ file bar
bar: symbolic link to `foo'
-bash-4.1$ if [ -d bar ]; then echo "bar is a directory"; fi
bar is a directory
-bash-4.1$ if [ -h bar ]; then echo "bar is a symlink"; fi
bar is a symlink
-bash-4.1$ bash -version
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

If this is intended behavior, the manual page and other documentation
should be updated to reflect it.

Thanks.

Open pipe passed to child process

[Adam Danischewski]

I'm not sure if this is a bug, or a feature but I had to debug some code as
a result so I'd like to bring it to your attention, and if you know of a
better way to read from pipes please let me know.

#!/bin/bash
numstr=${1}
rdlnk=$(readlink /proc/$$/fd/0)
function get_input() {
 ## echo "PID: $$, PPID: $PPID " && sleep 500
 ## What works is:
 ## if grep -Eq "^pipe:|deleted" <<< "${rdlnk}" && [[ "${rdlnk}" !=
"$(readlink /proc/$PPID/fd/0)" ]]; then
 if grep -Eq "^pipe:|deleted" <<< "${rdlnk}"; then
  while IFS= read -r piped_input || break; do
numstr="${numstr}${piped_input}"; done
 elif [[ -f "${rdlnk}" ]]; then
  numstr=$(head -1 "${rdlnk}")
 elif [[ -e "${numstr}" ]]; then
  numstr=$(head -1 "${numstr}")
 fi }

get_input
echo "the number string ${numstr} ..."
exit 0

I have fixed this problem as you can see in the comment in the code
itself, by looking at the parent process fd0.

Note: If you want to take a closer look at this, you may want to
uncomment the first line and take a look at ls -al
/proc/[PID|PPID]/fd/0.

To test this out, save the script above to a file /tmp/test.bsh.

$> for a in {1..5}; do /tmp/test.bsh "$a"; done
the number string 1 ...
the number string 2 ...
the number string 3 ...
the number string 4 ...
the number string 5 ...

$> while read a; do /tmp/test.bsh "$a"; done < <(seq 1 5)
the number string 12345 ...

If you swap commented conditionals you will see that both now work properly.

Is this supposed to happen? I don't see the point of writing the open pipe
to fd0 in the child process in this case.

Re: Open pipe passed to child process

[Adam Danischewski]

I was expecting it to be the pts.

On Tue, Aug 23, 2016 at 4:58 PM, Chet Ramey  wrote:

> On 8/23/16 2:28 PM, Adam Danischewski wrote:
> > I'm not sure if this is a bug, or a feature but I had to debug some code
> as
> > a result so I'd like to bring it to your attention, and if you know of a
> > better way to read from pipes please let me know.
>
> Just so I'm not confused: you mean that you don't want the process
> substitution to be open as file descriptor 0 in /tmp/test.bsh?  The
> redirection makes the pipe resulting from the process substitution
> file descriptor 0 for the duration of the while loop.  Child processes
> inherit file descriptor 0 from their parent.  What would you rather have
> as the standard input for the script in this case?
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~
> chet/
>
>

Re: Open pipe passed to child process

[Adam Danischewski]

Let's put aside the fs type for second and talk about what data should be
there and what should and shouldn't happen.

When a parent script kicks off a child process, and the child process reads
from fd0 I don't expect the child to be capable of manipulating the parents
pipe data on fd0. An error potentially but not quietly eating up the
parents fd0 pipe data. This seems to be violating a basic tenet.

I have tested this out in Solaris 10, and this does not happen there,
although fd0 does appear to be a pipe (parents pipe?). You may want to look
at the differences between the Solaris Bash code and Linux Bash code.

On Wed, Aug 24, 2016 at 2:09 PM, Chet Ramey  wrote:

> On 8/24/16 12:09 PM, Adam Danischewski wrote:
> > I was expecting it to be the pts.
>
> OK.  That's just not how it works.
>
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~ch
> et/
>

Re: Open pipe passed to child process

[Adam Danischewski]

Actually I misspoke before, there *is *this issue on Solaris 10. I didn't
update the logic sufficiently to detect it at first. So it looks like this
is could be a potentially more significant issue -- affecting enterprise
user markets.

I think the bottom line question is, should a child process be capable of
manipulating the parent processes pipe data. My vote is that it should not
be allowed, since I do not want things like a squirrely child process
eating up parent pipe data in my while/read loops. There may be important
tasks that are subsequent that I would not want a child process to
short-circuit.

On Wed, Aug 24, 2016 at 2:52 PM, Adam Danischewski <
adam.danischew...@gmail.com> wrote:

> Let's put aside the fs type for second and talk about what data should be
> there and what should and shouldn't happen.
>
> When a parent script kicks off a child process, and the child process
> reads from fd0 I don't expect the child to be capable of manipulating the
> parents pipe data on fd0. An error potentially but not quietly eating up
> the parents fd0 pipe data. This seems to be violating a basic tenet.
>
> I have tested this out in Solaris 10, and this does not happen there,
> although fd0 does appear to be a pipe (parents pipe?). You may want to look
> at the differences between the Solaris Bash code and Linux Bash code.
>
> On Wed, Aug 24, 2016 at 2:09 PM, Chet Ramey  wrote:
>
>> On 8/24/16 12:09 PM, Adam Danischewski wrote:
>> > I was expecting it to be the pts.
>>
>> OK.  That's just not how it works.
>>
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>  ``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, UTech, CWRUc...@case.edu
>> http://cnswww.cns.cwru.edu/~chet/
>>
>
>

Bash -f Test Operator - Not working as expected

[Adam Danischewski]

$ ls -al
/mnt/samsung32/.word_list_repo/instruments_song_repo/546725_pinstripe.mp3
lrwxrwxrwx 1 cronkilla cronkilla 74 Apr 29 19:30
/mnt/samsung32/.word_list_repo/instruments_song_repo/546725_pinstripe.mp3
->
/mnt/samsung32/.word_list_repo/master_song_repo/0/4/5/546725_pinstripe.mp3
$ [[ -L
"/mnt/samsung32/.word_list_repo/instruments_song_repo/546725_pinstripe.mp3"
]] && echo hi
hi
$ [[ ! -L
"/mnt/samsung32/.word_list_repo/instruments_song_repo/546725_pinstripe.mp3"
]] && echo hi
$ [[ -f
"/mnt/samsung32/.word_list_repo/instruments_song_repo/546725_pinstripe.mp3"
]] && echo hi
hi

It looks like the test operator "-f" is not functioning as described,
according to the documentation this should only return true on a REGULAR
file, not a symbolic link.

You can repeat the behavior by creating any symbolic link to a file or
directory and then using the test operator on the command line.

cd /tmp
touch test.txt
ln -s test.txt lnk2test
[[ -f lnk2test ]] && echo hi
[[ -L lnk2test ]] && echo hi
[[ ! -L lnk2test ]] && echo hi

The first test above -f should fail yet doesn't, the last negated symbolic
link test may be a workaround for finding a regular file unless you see
something wrong with that.

Bash does not complete the filename once the situation becomes singular

[Adam Purkrt]

GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
OS: Gentoo Linux


Originally met this while the download of iso file in firefox was
nearing completion, and I was preparing myself to move the
downloaded foobar.iso file elsewhere. I opened terminal with bash,
typed "mv foobar." in the Downloads dir and pressed . Two options
appeared: foobar.iso and and foobar.[somecode].iso.part. I kept pressing
, but after the download finished, with repeated presses bash kept 
displaying "foobar.iso" as a single option of completion and did not

complete to the already singular name.


Steps to reproduce:

1) in one instance of bash, run
touch foobar.a; touch foobar.b; sleep 10; rm foobar.b
2) run second instance concurrently, type "ls foobar.",
press  twice to get the two options existing at that moment
("foobar.a" and "foobar.b")
3) keep pressing  repeatedly
4) as the 10 seconds pass and the situation becomes clear and
complete-able, "foobar.a" is never completed to with repeated
presses of , it is (strangely) only displayed as a single
option for completion.

The result on screen around the 10th second looks as follows:

# ls foobar.
foobar.a  foobar.b
# ls foobar.
foobar.a  foobar.b
# ls foobar.
foobar.a
# ls foobar.
foobar.a
# ls foobar.
foobar.a


Expected behaviour:

Bash should complete to "foobar.a" as soon as it is an unique option,
i.e. as soon as foobar.b is removed after 10 seconds. Offering a
singular option for completion does not make sense anyway.


Additional note:

Also, when, in the erroneous situation after the 10 seconds elapsed, the
"." at the end of filename is deleted and written again (visually the 
same situation) and then  is pressed, the completion succeeds.

How do I subscribe to this mailing list

[Grzegorz Adam Hankiewicz]

I'm reading http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html
and I see no instructions on how to subscribe to this mailing
list. I've checked http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html
too and there's no info there.

Any info?


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Visual completion ellipsis

[Grzegorz Adam Hankiewicz]

Here's a proposed patch for Bash (or readline) which implements a
usability feature.  This feature reduces the amount of text output
when filename completion shows a list of files after pressing TAB
twice (or once if you configure it so), showing as first letter
what you have to type to disambiguate the completion. Here's an
output example:

  [0:[EMAIL PROTECTED]:0] [~/project/bash-3.1-ellipsis]$ ./bash
  [EMAIL PROTECTED]:~/project/bash-3.1-ellipsis$ ls ar
  ___.c ...func.c ...func.h ...func.o ___.h ___.o
  [EMAIL PROTECTED]:~/project/bash-3.1-ellipsis$ ls array

As you can see, instead of showing the full name, an ellipsis
replaces the common prefix in the list.  This is more helpful the
longer the names get:

  [EMAIL PROTECTED]:~/project/bash-3.1-ellipsis$ ls ~/all
  ...df   ...s.gz
  [EMAIL PROTECTED]:~/project/bash-3.1-ellipsis$ ls ~/allegro-manual-4.0.3.en.p

The patch is not implemented for multibyte (don't know how to deal
with that) and it would be better if the length of the ellipsis
could be set at runtime rather than with a define. I wonder if you
would like to merge this patch with the main distribution. Please
tell me what modifications would I have to do, if you so desire.

Now, about the long story of this improvement. I started thinking
about it during April of 2003. The 16th of that month I mailed
[EMAIL PROTECTED] asking what would be the procedure to
collaborate a patch implementing this feature. While I waited for
an answer (which never came), I implemented this for bash 2.x and
used it just myself.

Years later I realise I forgot to contribute the patch digging
through an old mailbox.  This time, the 29th of October of 2005
I try luck with [EMAIL PROTECTED] Again, no luck. This time I
even included the patch for bash 2.x.

Nearly a month later, despite a lack of instructions, I manage to
subscribe to this mailing thanks to the answers of Bob Proulx and
Chet Ramey. Lurking here, I see no trace of active development,
no information about the process of submitting patches, no real
hint of what somebody would have to do to contribute one...

It just looks very very sad that two presumably valid email
addresses don't have anybody reading their mail (or somebody not
bothering to answer), and even instructions about mailing list
subscription are hidden and have to be asked or discovered. Isn't
the bash/readline community preventing software contributions
through lack of communication?

I yet have to find if there is any source control software in use,
so I could make a diff against some sort of development branch. I
wonder, is there any or you guys control things by hand?
diff -u -r bash-3.1/doc/bashref.info bash-3.1-ellipsis/doc/bashref.info
--- bash-3.1/doc/bashref.info   2005-10-03 21:07:32.0 +0200
+++ bash-3.1-ellipsis/doc/bashref.info  2005-12-10 22:43:09.091010680 +0100
@@ -5986,6 +5986,12 @@
   `insert-comment' command is executed.  The default value is
   `"#"'.
 
+`completion-ellipsis'
+  If set to `on', Readline will transform the common prefix
+  of matched words in an ellipsis when showing possible
+  options, if the prefix is longer than three characters.
+  The default value is `off'.
+
 `completion-ignore-case'
   If set to `on', Readline performs filename matching and
   completion in a case-insensitive fashion.  The default value
diff -u -r bash-3.1/lib/readline/bind.c bash-3.1-ellipsis/lib/readline/bind.c
--- bash-3.1/lib/readline/bind.c2005-10-14 17:04:27.0 +0200
+++ bash-3.1-ellipsis/lib/readline/bind.c   2005-12-10 22:39:20.485763960 
+0100
@@ -1383,6 +1383,7 @@
   { "bind-tty-special-chars",  &_rl_bind_stty_chars,   0 },
   { "blink-matching-paren",&rl_blink_matching_paren,   V_SPECIAL },
   { "byte-oriented",   &rl_byte_oriented,  0 },
+  { "completion-ellipsis", &_rl_completion_ellipsis,   0 },
   { "completion-ignore-case",  &_rl_completion_case_fold,  0 },
   { "convert-meta",&_rl_convert_meta_chars_to_ascii, 0 },
   { "disable-completion",  &rl_inhibit_completion, 0 },
diff -u -r bash-3.1/lib/readline/complete.c 
bash-3.1-ellipsis/lib/readline/complete.c
--- bash-3.1/lib/readline/complete.c2005-10-08 04:30:18.0 +0200
+++ bash-3.1-ellipsis/lib/readline/complete.c   2005-12-10 22:36:58.844296736 
+0100
@@ -110,8 +110,8 @@
 static int _rl_internal_pager PARAMS((int));
 static char *printable_part PARAMS((char *));
 static int fnwidth PARAMS((const char *));
-static int fnprint PARAMS((const char *));
-static int print_filename PARAMS((char *, char *));
+static int fnprint PARAMS((const char *, const int));
+static int print_filename PARAMS((char *, char *, int));
 
 static char **gen_completion_matches PARAMS((char *, int, int, 
rl_compentry_func_t *, int, int));
 
@@ -160,6 +160,11 @@
 int _rl_completion_case_fold;
 #endif
 
+/* If non-zero, the common 

Re: Bash - various feature requests

[Grzegorz Adam Hankiewicz]

On 2006-12-27, Richard Neill <[EMAIL PROTECTED]> wrote:
> 1)substr support for a negative length argument.
> For example,
>   stringZ=abcdef
>   echo ${stringZ:2:-1}  #prints cde
>
> i.e. ${string:x:y}
>   returns the string, from start position x for y characters.
>   but, if x is negative, start from the right hand side
>   and if y is negative, print up to the end, -y.
>
> This would work the same way as PHP, and be extremely useful for, say,
> removing an extension from a filename.

If extension removal is all you need, you can already do it.

$ for f in *; do echo $f; done
Makefile.am
Makefile.in
ucl
$ for f in *; do echo ${f%.*}; done
Makefile
Makefile
ucl

See "Parameter Expansion" in the bash manual. Interestingly that same
section tells for '${parameter:offset}' expansion:

"If offset evaluates to a number less than  zero,  the value
is used  as  an  offset  from the end  of the value of parameter."

However, if I use echo ${f:-3} I don't get the expected result. I wonder
if this is a bug of my bash version:

$ bash --version
GNU bash, version 3.00.16(1)-release (i486-pc-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
$ for f in *; do echo ${f:-3}; done
Makefile.am
Makefile.in
ucl

It works with ${f:0-3}, which is odd, at least from my point of view.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bash - various feature requests

[Grzegorz Adam Hankiewicz]

On 2006-12-29, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Read the second last sentence of the paragraph.

Makes sense.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash