Re: strange 'delayed' aliases

[Jonathan]

On Dec 23, 7:34 am, Chet Ramey  wrote:
> I would think so, since you've inserted a command continuation (the escaped
> newline) into the command via the alias.  It's the same as if you had typed
>
> *$* echo \
> *>* Hello, World!
>
> The only unexpected part is the re-issuing of $PS1 as opposed to $PS2.
> I'll have to take a look at that.

It certainly seems to be related to command continuations. Here are a
few more symptoms:

1) Text on the same line as the alias is run directly as a separate
command. Bash doesn't see it as part of the original command:
$ x Hello
$ World!

Hello: command not found

2) Adding text to the second line of the alias causes the alias to run
immediately but the added text is ignored:
$ alias x='echo \
> Hello'
$ x

$

3) Adding text before the continuation in the alias causes the command
history to report the second line as a separate command:
$ alias x='echo Hello, \
> '
$ x
$ World!
Hello, World!
$ history 2
  481  x; World!
  482  history 2

Hope this helps.

- Jonathan

Re: 'test' builtin of bash returns wrong value for '! -a FILE' operation

[Jonathan Nieder]

tags 426990 - moreinfo
tags 426990 + upstream
# documentation bug
severity 426990 minor
retitle 426990 bash: "help test" gives no hint of complicated precedence rules
quit

OZAKI Masanobu wrote:
> On Fri, 2010-11-05 at 03:17:13 -0500, Jonathan Nieder  
> wrote:

>>> Please try
>>>   % bash -c 'test ! -a . && echo true'
>>> and compare with the result of
>>>   % bash -c '/usr/bin/test ! -a . && echo true'
>>
>> So which one is right?
>
> Both should echo "true", but the former did not: I found that the former
> sometimes returns the correct result, but have not found what makes the
> difference.

Thanks.  The second one doesn't echo "true", does it?

Summarizing: There are two -a operators: a unary one and a binary one.
This results in reduce/reduce conflicts when parsing a "test" expression.

"help test" says:

See the bash manual page bash(1) for the handling of
parameters (i.e., missing parameters).

which does not really tempt me to look at the manual.  bash(1) says:

Expressions may be combined using the following
operators, listed in decreasing order of precedence.

giving an order of precedence with ! before -a.  Then it quickly
corrects itself:

test and [ evaluate conditional expressions using a set
of rules based on the number of arguments.

0 arguments
The expression is false.
[...]
3 arguments
If the second argument is one of the
binary conditional operators listed above
under CONDITIONAL EXPRESSIONS, the result
of the expression is the result of the
binary test using the first and third
arguments as operands.  The -a and -o
operators are considered binary operators
when there are three arguments.

That answers the question.  Unfortunately, the next sentence is
inconsistent with that answer:

 If the first
argument is !, the value is the negation of
the two-argument test using the second and
third arguments.

Suggested changes:

 1. Change the parenthesis in "help bash" to something like
"(e.g., operator precedence and missing parameters)".

 2. Change the second paragraph in the description in bash(1) of
the test builtin to something like

Expressions may be combined using the following operators.
The evaluation depends on the number of arguments; see below.
When 5 or more arguments are present, this list is in
decreasing order of precedence.

 3. Add the word "Otherwise," before "If the first argument is !" in
the 3-argument case.

Thoughts?  I can try writing a patch if this looks like a good idea.

PS1 has ruined line wrap

[Jonathan Reed]

I was using this as my ps1
PS1='[...@\[\e[1;31m\]\h\[\e[0m\]:$PWD]\$ '

But I wanted to label the title of my xterm windows with the hostname of
system Im logged into. So I added the following
PS1='[...@\[\e[1;45m\]\h\[\e[0m\] $PWD]\e]2;@ \H\a\$ '

It works great except for it rewrites the current line if I write text past
the current window size (regardless of the window size).
filenameERVERNAME:/home/jreed]$ cat /a/really/long_fi

Any suggestions?

Thanks,
Jonathan

Re: PS1 has ruined line wrap

[Jonathan Reed]

An old thread but I found a way around this by adding a line to my bashrc:

echo -ne "\033]0; `whoami` @ `hostname` \007"

The reference
http://mdinh.wordpress.com/2010/11/21/xterm-title-bar/

On Thu, Nov 25, 2010 at 7:26 PM, Chet Ramey  wrote:

> On 11/25/10 3:38 PM, Jonathan Reed wrote:
> > I was using this as my ps1
> > PS1='[\u@\[\e[1;31m\]\h\[\e[0m\]:$PWD]\$ '
> >
> > But I wanted to label the title of my xterm windows with the hostname of
> > system Im logged into. So I added the following
> > PS1='[\u@\[\e[1;45m\]\h\[\e[0m\] $PWD]\e]2;@ \H\a\$ '
> >
> > It works great except for it rewrites the current line if I write text
> past
> > the current window size (regardless of the window size).
> > filenameERVERNAME:/home/jreed]$ cat /a/really/long_fi
> >
> > Any suggestions?
>
> You might consider bracketing all sequences of non-printing characters
> with \[ and \].
>
>
>
> --
> ``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/
>

Re: PS1 has ruined line wrap

[Jonathan Reed]

>
> around all the characters that don't move the cursor


portion immediately after the $PWD


Thanks for the clarity guys. It took me a few minutes to see the matching
[]'s and to escape the correct ones. My syntax highlighting was confusing me
but I think my enemy is that I'm trying to use the [] characters in my
prompt and that they are also control characters here. But heres what I
ended up with and this works.
PS1='[\u@\[\e[1;45m\]\h\[\e[0m\] $PWD\[\e]2;@ \H\a\]]\$ '

I was mainly concerned only with the system name in the title bar to help me
feel in a little more control in my window manager. But you are correct in
saying that my .bashrc workaround is not the proper way to handle my problem
since it does not handle a scenario where multiple logouts are performed
after a chain of logins.


On Mon, Feb 14, 2011 at 9:30 AM, Chet Ramey  wrote:

> On 2/12/11 2:53 PM, Jonathan Reed wrote:
> > An old thread but I found a way around this by adding a line to my
> bashrc:
> >
> > echo -ne "\033]0; `whoami` @ `hostname` \007"
> >
> > The reference
> > http://mdinh.wordpress.com/2010/11/21/xterm-title-bar/
> >
> > On Thu, Nov 25, 2010 at 7:26 PM, Chet Ramey  > <mailto:chet.ra...@case.edu>> wrote:
> >
> > On 11/25/10 3:38 PM, Jonathan Reed wrote:
> > > I was using this as my ps1
> > > PS1='[\u@\[\e[1;31m\]\h\[\e[0m\]:$PWD]\$ '
>
> That works.
>
> > > But I wanted to label the title of my xterm windows with the
> hostname of
> > > system Im logged into. So I added the following
> > > PS1='[\u@\[\e[1;45m\]\h\[\e[0m\] $PWD]\e]2;@ \H\a\$ '
>
> The portion immediately after the $PWD is probably going to be invisible
> and cause you problems.
>
> Chet
> --
> ``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/
>

Re: cd --help should output the complete man page

[Jonathan Nieder]

Hi Faheem,

Faheem Mitha wrote:

>   $ cd --help
>   bash: cd: --: invalid option
>   cd: usage: cd [-L|-P] [dir]
>
> I'm don't even know how to get the usage output without
> inducing an error.

Does "help cd" do the trick?

> I think a man page might also be a good idea. You may
> also be aware that in current Debian, the bash manual is not
> packaged

"man builtins" works for me.  It might be worth a wishlist bug to
install cd.1.gz as a symlink to ../man7/builtins.7.gz.

By the way, at least on Debian, we are not quite POSIX conformant with
respect to "cd" and similar non-special builtins.  There should be a
wrapper script on the $PATH so programs using the exec family of
functions can use them (see XCU 1.6 "Built-in utilities").

Re: bash: $() doesn't preserve new lines

[Jonathan Nieder]

Hi again,

Dmitry Baryshev wrote:
> 2011/4/14 Jonathan Nieder 

>> ?  Note that 'echo' is an ordinary built-in utility, which will behave
>> in most respects like an external utility.  So the expansion gets
>> passed to it as a sequence of arguments.  As "help echo" does not
>> explain
>
> Yes, I believe it should mention this
> 
>> (but could), it concatenates its arguments using a single
>> space as delimiter.

Sure, makes sense.  Care to suggest a wording?

Thanks,
Jonathan

Re: bug on [A-Z] and [a-z]

[Jonathan Nieder]

Hi,

ri...@inf.ufpr.br wrote:

>   When  running "echo [A-Z]*" , it shows all files/dirs of current
> directory, not only those starting with capital letters. I tried
> different locales such as: POSIX, C, en_US, pt_BR
>
> Repeat-By:
> $ mkdir a && cd a
> $ touch a b c; mkdir D E F
> $ echo [A-Z]*
> b c D E F
> $ echo [a-z]*
> a b c D E F

See http://bugs.debian.org/301717 (“fnmatch("[a-z]", ...) matches
capital letters in most locales”) for some details.

I'm puzzled by your comment on trying different locales, though:
I tried

mkdir a && cd a
touch a b c; mkdir D E F
echo [A-Z]*

and got output

b c D E F

as expected.  Then I tried

LANG=C
export LANG
echo [A-Z]*

and got output

D E F

Does your experience differ?  I'm using 4.1.5(1)-release fwiw.

> No Fix yet, looking on the source code.

In the long run, a good fix might be to teach fnmatch a new
FNM_STRICTCASE flag and optionally use it.  The hardest part would
seem to be making tables so the system can know what "this range,
using the same case" means.  If you'd like to work on this, please
feel free to coordinate using the aforementioned libc bug report (and
cc-ing me).

A separate aspect is documentation.  I imagine Chet wouldn't mind
a patch to bash.1 and bash.info to explain this pitfall under
"Pattern Matching" or even under "BUGS" (aka LIMITATIONS).

Hope that helps,
Jonathan

Re: eval

[Jonathan Nieder]

Hi Rafael,

Rafael Fernandez wrote:

> set -- a b c d e f g h i j k l m n o p q r s t u v w x y z
> i=1
> eval echo '$'$i # outputs an expected 'a'
> i=10
> eval echo '$'$i # outputs 'a0'; expected 'j'
> i=11
> eval echo '$'$i # outputs 'b1'; expected 'k'

Have you tried

eval "echo \${$i}"

?

Re: eval

[Jonathan Nieder]

Rafael Fernandez wrote:

> Thanks, I wasn't aware that positional parameters greater than nine have to
> be enclosed in brackets.

No prob.  The manpage says

When a positional parameter consisting of more than a single
digit is expanded, it must be enclosed in braces (see
EXPANSION below).

If you have an idea for making this clearer (maybe somewhere in the
info documentation) I imagine it would be welcome.

For the future, the sh specification at
http://www.unix.org/2008edition/ (free registration required) is also
very useful for tracking down how a shell might understand a script.

[PATCH/RFC] bash.1: "shopt -s checkwinsize" has no effect in non-interactive shells

[Jonathan Nieder]

Explain that COLUMNS and LINES are not set automatically in
non-interactive shells, and recommend direct use of the tput utility
from ncurses as a replacement.

Fixes: http://bugs.debian.org/628638
Reported-by: Leslie A Rhorer 
Helped-by: Leslie A Rhorer 
---
Hi Chet et al,

Here's a quick documentation patch, based on the report mentioned
above.  Thoughts of all kinds welcome.

 doc/bash.1 |   14 ++
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/doc/bash.1 b/doc/bash.1
index 1890b3c..4df0986 100644
--- a/doc/bash.1
+++ b/doc/bash.1
@@ -1802,7 +1802,10 @@ being closed.
 .TP
 .B COLUMNS
 Used by the \fBselect\fP builtin command to determine the terminal width
-when printing selection lists.  Automatically set upon receipt of a SIGWINCH.
+when printing selection lists.  Automatically set in interactive shells
+upon receipt of a SIGWINCH.
+To obtain the width of the terminal in a non-interactive shell,
+use \fBCOLUMNS\fP=$(tput cols).
 .TP
 .B COMPREPLY
 An array variable from which \fBbash\fP reads the possible completions
@@ -2021,9 +2024,12 @@ This variable determines the locale category used for 
number formatting.
 .TP
 .B LINES
 Used by the \fBselect\fP builtin command to determine the column length
-for printing selection lists.  Automatically set upon receipt of a
+for printing selection lists.  Automatically set in interactive shells
+upon receipt of a
 .SM
 .BR SIGWINCH .
+To obtain the width of the terminal in a non-interactive shell,
+use \fBLINES\fP=$(tput lines).
 .TP
 .B MAIL
 If this parameter is set to a file name and the
@@ -8732,8 +8738,8 @@ above).  The shell always
 postpones exiting if any jobs are stopped.
 .TP 8
 .B checkwinsize
-If set, \fBbash\fP checks the window size after each command
-and, if necessary, updates the values of
+If set and the shell is interactive, \fBbash\fP checks the window size
+after each command and, if necessary, updates the values of
 .SM
 .B LINES
 and
-- 
1.7.5.3

Re: printf treats arguments of "%c" not as expected

[Jonathan Nieder]

Hi,

Yunfeng Wang wrote:

> $ printf %c 65 66 67
> 666
>
> The expected output is ABC, i.e. characters with ASCII code of 65 66 67

I believe the current behavior is correct.  POSIX (XCU.4.printf) sayeth[*]:

11. The argument to the 'c' conversion specifier can be a string
containing zero or more bytes.  If it contains one or more
bytes, the first byte shall be written and any additional bytes
shall be ignored.  If the argument is an empty string, it is
unspecified whether nothing is written or a null byte is written.

I would suggest using something like

perl -e 'print(chr(65), chr(66), chr(67), "\n");'

or

for i in 65 66 67
do
eval printf \'\\$(printf %03o "$i")\'
done
printf '\n'

for your application.

Back to the bug: I don't see any explanation of "printf %c" when I run
"man bash".  Perhaps your manual is different from mine, but if you,
perhaps it would be possible to suggest a few words to explain this
for future readers.

Thanks and regards,
Jonathan

[*] http://unix.org/2008edition/

License details for bash-4.2

[Jonathan Nieder]

r.sin po/remove-potcdate.sin

I can't find license notices for these.  That's probably not
too important but it would be nice to clarify what the terms
are.

aclocal.m4 configure po/bash.pot po/*.gmo cross-build/*.cache

Generated files/configure scripts --> not a big deal.

AUTHORS CRWU/PLATFORMS MANIFEST MANIFEST.doc Y2K doc/htmlpost.sh
doc/infopost.sh examples/INDEX.* lib/glob/doc/Makefile
lib/glob/doc/glob.texi lib/glob/ndir.h lib/intl/ChangeLog
lib/intl/VERSION lib/readline/STANDALONE
po/LINGUAS po/README po/boldquot.sed support/SYMLINKS

These files are probably too trivial for copyright, anyway.

I'll be happy to follow-up with individual copyright holders but
thought I should ask here first in case there is information available
that could save the trouble.

Thanks and regards,
Jonathan

License of bash manpage (Re: License details for bash-4.2)

[Jonathan Nieder]

Hi Chet et al,

Jonathan Nieder wrote:

[concerning licensing]
> Looking over bash 4.2, I have a few questions:

After investigating a little more and testing with files removed, I'm
down to one question (though it would still be nice to clarify the
licenses of the other files mentioned): what is the intended license
of the bash manpage at doc/bash.1, if any?

The opening comments only say

.\" MAN PAGE COMMENTS to
.\"
.\" Chet Ramey
.\" Case Western Reserve University
.\" c...@po.cwru.edu
.\"
.\" Last Change: Tue Dec 28 13:41:43 EST 2010

I am interested in whether you are okay with users and distributors
using, modifying, and distributing the file, and if so under what
terms.

Thanks for writing the manpage, by the way!  It is generally a
pleasant read and very clear.

Regards,
Jonathan

Re: License of bash manpage (Re: License details for bash-4.2)

[Jonathan Nieder]

Chet Ramey wrote:

> The man page copyright belongs to me -- I don't know that I ever
> assigned it to the FSF.  I don't have a problem with others modifying the
> man page, and expect it under certain circumstances.  For instance, if a
> distribution modifies the startup files bash reads (e.g., to add
> /etc/bash.bashrc as some have done), I expect them to modify the manual
> page in the distribution to reflect that.
>
> In other cases, I would prefer that any changes get sent back to me
> so I can modify as necessary for future releases.

Perfect, thanks.  Does the same go for bashbug.1, too?  (Sorry I forgot
to ask about it before.)

Ah, one more question.  The tests/COPYRIGHT file says:

Unless otherwise stated, all files in this directory are Copyright (C)
1991,1992,1993,1994,1995,1996,1997,1998,1999,2000,2001,2002,2003,
2004,2005,2006,2007,2008,2009
Free Software Foundation, Inc.

The file ifs-posix.tests is Copyright (C) 2005 Glen Fowler.

Do you know what the license terms are for the test suite?  In
particular, is it okay to use, modify, and distribute these files?

I'll try to get in touch with some of the people who submitted example
functions and scripts to find out their wishes.

Cheers,
Jonathan

Re: License of bash manpage (Re: License details for bash-4.2)

[Jonathan Nieder]

Chet Ramey wrote:

> I wrote the entire test suite except for the one file from Glen Fowler.
> It is (or should be) copyright GPL3 just like the rest of the distribution.

Just wanted to say thanks for the clear and quick responses.  They helped.

Jonathan

Re: integer addition crash

[Jonathan Nieder]

Hi Cédric,

Cédric Martínez Campos wrote:

>   $ echo $((08+1))
>   bash: 08: too big element for the base (the error element is "08")
> [translated from spanish]

Strings of digits starting with a '0' in an arithmetic expansion are
octal numbers.  The bash FAQ[*] has some details.

Hope that helps,
Jonathan

[*] http://tiswww.case.edu/php/chet/bash/FAQ
question E8 ("Why does the arithmetic evaluation code complain about
`08'?")

bash completion

[jonathan MERCIER]

I have a bash completion file (see below)
It works fine, but i would like add a feature => not expand the flag by
a space when it contain '='
curently when i do:
$ ldc2 -Df
ldc2 -Df=⊔
i would like:
 ldc2 -Df
ldc2 -Df=

without space

tanks a lot
---
# bash completion for ldc
_ldc()
{
local cur prev opts opts_with_path
COMPREPLY=()
cur="${COMP_WORDS[COMP_CWORD]}"
prev="${COMP_WORDS[COMP_CWORD-1]}"
opts_with_path="-Dd= -Df= -Hd= -Hf= -I= -Xf= od= -of=
-profile-info-file= "
opts="  -D -Dd= -Df= -H -Hd= -Hf= -I= -J= -L= -O -O0 -O1 -O2 -O3 -O4
-O5 -X -Xf= -annotate -asm-verbose -c \
-check-printf-calls -code-model =medium -d
-d-debug= -d-version -debuglib -defaultlib \
-deps -enable-asserts -enable-boundscheck -disable-d-passes
-disable-excess-fp-precision -disable-fp-elim \
-disable-gc2stack -disable-non-leaf-fp-elim
-enable-preconditions -disable-red-zone \
-disable-simplify-drtcalls -disable-spill-fusing
-enable-contracts -enable-correct-eh-support \
-enable-fp-mad -enable-inlining -enable-invariants
-enable-load-pre -enable-no-infs-fp-math \
-enable-no-nans-fp-math -enable-postconditions -ena
-enable-unsafe-fp-math -fdata-sections \
-ffunction-sections -float-abi Generating debug information:
-g -gc -help -ignore \
-internalize-public-api-file= -internalize-public-api-list=
-jit-emit-debug -jit-enable-eh \
-join-liveintervals -limit-float-precis -linkonce-templates
-m32 -m64 -march= -mattr= -mcpu= -mtriple= \
-nested-ctx -noasm -noruntime - -nozero-initialized-in-bss
-o- -od= -of= -op -oq -output-bc -output-o \
-output- -pre-RA-sched  -print-after -print-after-all
-print-before -print-before-all -print-machineinstrs \
-profile-estimator-loop-weight= -profile-info-file=
-profile-verifier-noassert \
-regalloc -rel =dynamic-no-pic -rewriter -run= -shrink-wrap
-singleobj -soft-float -spiller -st \
-stack-protector-buffer-size= -stats -tailcallopt
-time-passes -unittest -unwind-tables -v \
"
if [[ ${opts_with_path} =~ ${prev} ]] ; then
COMPREPLY=( $(compgen -f ${cur}) )
return 0
elif [[ ${cur} == -* ]] ; then
COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
return 0
fi
}
complete -F _ldc ldc2


-

Re: bash completion

[jonathan MERCIER]

Le mardi 09 août 2011 à 10:05 +0800, Clark J. Wang a écrit :
> On Sun, Aug 7, 2011 at 11:35 PM, jonathan MERCIER
>  wrote:
> I have a bash completion file (see below)
> It works fine, but i would like add a feature => not expand
> the flag by
> a space when it contain '='
> curently when i do:
> $ ldc2 -Df
> ldc2 -Df=⊔
> i would like:
>  ldc2 -Df
> ldc2 -Df=
> 
> without space
> 
> 
> Try like this:
> 
> complete -o nospace -F _ldc ldc2

tanks a lot, works fine

[SOLVED]

Re: pwd as first command changes script behavior

[Jonathan Nieder]

Hi Sam,

Quiring, Sam wrote:

> #! /bin/bash
> pwd
> echo $_
>
> #! /bin/bash
> echo $_
> pwd
>
> The first one displays:
> /home/windriver/changes/NexS-235r1/with-camera
> pwd
>
> The second one displays:
> ./apply.sh
> /home/windriver/changes/NexS-235r1/with-camera

That's what $_ is advertised to do: it expands to the last
argument to the previous command, after expansion (or the full
pathname to the shell or shell script if there was no previous
command).  You're probably looking for $(which $0) or something
similar.

Hope that helps,
Jonathan

Bug: shell history loses lines beginning with # in a here-document

[Jonathan Wakely]

[I've just created a bug report at Savannah, but looking at the Bash
page on gnu.org I realised it should have ben sent here rather than
]

Run these command:

$ gcc -x c - <
 int main() { printf("hi\n"); }
 EOT
$ ./a.out
hi

now use the up cursor (or "fc -2" or any equivalent) to return to the
gcc command, it has been
mangled to:

gcc -x c - <

Re: Execution strange when get lines of the console in script with command substitution and the rediretion of the stderr.

[Jonathan Nieder]

(+cc: help-bash, -cc: bug-bash, bcc: bug-bash)
Hi,

QGZ wrote:

> $ cat abc.sh
> #!/bin/bash
> tput lines
> echo $(tput lines)
[...]
> $ ./abc.sh 2>/dev/null
>
> We will get :
> 50
> 24

This is an ncurses question, not a "bash" question, so let's move to
the help-bash list.

The tput(1) manual does not describe how it gets access to the
terminal to read the number of lines.  Fortunately, from your example
we can deduce that tput checks if the standard output (file
descriptor 1) and standard error (file descriptor 2) streams are
terminals and communicates with the terminal using whichever one is a
tty.  Something like

echo $(tput lines 2>/dev/tty)

might get your script working again.  A patch to the manual page from
the ncurses-bin package to clarify this would presumably be welcome.

> I don't know why it is.  What is amazing is the number 24. 

That's the traditional height of an 80x24 terminal.

Hope that helps.

Regards,
Jonathan

Re: Restricted Bash - Not so restrictive (in 4.2 as well)

[Jonathan Nieder]

Hi,

Sarnath K - ERS, HCLTech wrote:

> I see this problem in the latest Bash 4.2 as well. Say, I invoke
> "rbash" or "bash -r". This leaves me in a restrictive shell.
> However, this restrictive shell allows me to run "bash" or any other
> shell (without execing - just simply run) which leaves me in a
> normal shell.

Typically rbash is used with a nonstandard PATH setting to give users
access to a restricted set of commands.

However, I notice that the bash(1) manpage does not mention anything
about that.  If you can come up with a way to hint at it without
making the manpage much longer (maybe by tweaking the sentence that
starts "A restricted shell is used to set up an environment"), I
imagine that would be helpful.

Thanks and hope that helps,
Jonathan

Re: Restricted Bash - Not so restrictive (in 4.2 as well)

[Jonathan Nieder]

Sarnath K - ERS, HCLTech wrote:

> Apart from this, BASH Documentation says "When a command that is
> found to be a shell script is executed (see COMMAND EXECUTION
> above), rbash turns off  any  restrictions in the shell spawned to
> execute the script.".
>
> Does this mean that a guy with restricted shell can just write a
> shell script to do a privileged operation and get away with it?

"./my-custom-script" contains a "/".

Cross compile crapout

[Jonathan Andrews]

Trying to compile for an arm target I get this

execute_cmd.c: In function 'execute_pipeline':
execute_cmd.c:2205: error: 'job_control' undeclared (first use in this
function)
execute_cmd.c:2205: error: (Each undeclared identifier is reported only
once
execute_cmd.c:2205: error: for each function it appears in.)
execute_cmd.c: In function 'execute_function':
execute_cmd.c:4243: warning: passing argument 1 of 'array_rshift'
discards qualifiers from pointer target type
execute_cmd.c:4245: warning: passing argument 1 of 'array_rshift'
discards qualifiers from pointer target type
execute_cmd.c:4320: warning: passing argument 1 of 'array_shift'
discards qualifiers from pointer target type
execute_cmd.c:4321: warning: passing argument 1 of 'array_shift'
discards qualifiers from pointer target type
make: *** [execute_cmd.o] Error 1


I found the fix here, but it would be nice if it could work its way into
the source for the next release.  

http://lists.gnu.org/archive/html/bug-bash/2011-09/msg00039.html

Thanks,
Jon

Re: Cross compile crapout

[Jonathan Andrews]

On Sat, 2012-01-21 at 19:45 -0500, Chet Ramey wrote:
> On 1/21/12 11:13 AM, Jonathan Andrews wrote:
> 
> > I found the fix here, but it would be nice if it could work its way into
> > the source for the next release.  
> > 
> > http://lists.gnu.org/archive/html/bug-bash/2011-09/msg00039.html
> 
> This is patch 18 to bash-4.2.
> 

Ooops! I had not noticed it even had patches, sorry.

It might be worth mentioning the possible existence of patches in README
or INSTALL.

As is normal for projects I had limited time so I just googled "bash
src" and downloaded the newest. 

I needed a statically linked bash for testing an arm board. I did not
expect it to be nearly 3MB though ! It surprises me that a statically
linked bash is bigger than the entire busybox binary i've compiled, or
my kernel image for that matter. Is this bloat gcc, some failing of the
linker or bash itself?  

Thanks,
Jon

Re: Cross compile crapout

[Jonathan Andrews]

On Mon, 2012-01-23 at 20:30 -0500, Chet Ramey wrote:
> On 1/23/12 1:12 AM, Jonathan Andrews wrote:
> 
> > I needed a statically linked bash for testing an arm board. I did not
> > expect it to be nearly 3MB though ! It surprises me that a statically
> > linked bash is bigger than the entire busybox binary i've compiled, or
> > my kernel image for that matter. Is this bloat gcc, some failing of the
> > linker or bash itself?  
> 
> That's probably the size of the C library on your machine.  The only
> difference between a static bash and a `normal' bash is that the system
> libraries are linked in instead of being dynamically linked at run time.
Im not a gcc expect, I thought the idea of the linker was also to drop
unused code but this seems not to be true with gcc as default.  

http://www.google.com/url?sa=t&rct=j&q=gcc%20linker%20unused%20code&source=web&cd=5&ved=0CEYQFjAE&url=http%3A%2F%2Felinux.org%2Fimages%2F2%2F2d%2FELC2010-gc-sections_Denys_Vlasenko.pdf&ei=Tx8eT5mUGczRswaZju3eDA&usg=AFQjCNF3miTnzqYNsiiyei_SQDlDxG10TQ&cad=rja

http://gcc.gnu.org/ml/gcc-help/2003-08/msg00128.html

I've been trying to compile bash static with the extra parameters, no
joy so far - finger trouble on my part I expect.


> I built a minimal bash (--enable-minimal-config) on my machine (Mac OS X,
> where static linking isn't possible), and it ended up being about half
> as big as a bash-4.2.20 build.  I had to fix a few things to do it.
Maybe this is one of the things ?

I've applied the patches, tried this :

(script)
export CC=arm-softfloat-linux-gnu-gcc
./configure --build=i386-linux --host=arm-linux --enable-static-link 
--without-bash-malloc --enable-minimal-config
make


Get this :

arm-softfloat-linux-gnu-gcc  -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"arm"' 
-DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"arm-unknown-linux-gnu"' 
-DCONF_VENDOR='"unknown"' -DLOCALEDIR='"/usr/local/share/locale"' 
-DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g 
-O2 -c y.tab.c
./parse.y: In function 'shell_getc':
./parse.y:2399: error: label 'pop_alias' used but not defined
make: *** [y.tab.o] Error 1


Any ideas ?

Thanks,
Jon

Re: Cross compile crapout

[Jonathan Andrews]

On Tue, 2012-01-24 at 08:09 -0500, Chet Ramey wrote: 
> On 1/23/12 10:17 PM, Jonathan Andrews wrote:
> 
> > Im not a gcc expect, I thought the idea of the linker was also to drop
> > unused code but this seems not to be true with gcc as default.
> 
> Sure, but it's the difference between all of the libc functions you use
> and none of them, not what you use from libc and what you don't.
gcc never fails to surprise me, at the moment not in a positive way :-(

> > 
> > http://www.google.com/url?sa=t&rct=j&q=gcc%20linker%20unused%20code&source=web&cd=5&ved=0CEYQFjAE&url=http%3A%2F%2Felinux.org%2Fimages%2F2%2F2d%2FELC2010-gc-sections_Denys_Vlasenko.pdf&ei=Tx8eT5mUGczRswaZju3eDA&usg=AFQjCNF3miTnzqYNsiiyei_SQDlDxG10TQ&cad=rja
> > 
> > http://gcc.gnu.org/ml/gcc-help/2003-08/msg00128.html
> > 
> > I've been trying to compile bash static with the extra parameters, no
> > joy so far - finger trouble on my part I expect.
> > 
> > 
> >> I built a minimal bash (--enable-minimal-config) on my machine (Mac OS X,
> >> where static linking isn't possible), and it ended up being about half
> >> as big as a bash-4.2.20 build.  I had to fix a few things to do it.
> > Maybe this is one of the things ?
> 
> It is.  Just comment out the goto as a quick fix.
OK

> > 
> > I've applied the patches, tried this :
> > 
> > (script)
> > export CC=arm-softfloat-linux-gnu-gcc
> > ./configure --build=i386-linux --host=arm-linux --enable-static-link 
> > --without-bash-malloc --enable-minimal-config
> > make
> > 
> > 
> > Get this :
> > 
> > arm-softfloat-linux-gnu-gcc  -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"arm"' 
> > -DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"arm-unknown-linux-gnu"' 
> > -DCONF_VENDOR='"unknown"' -DLOCALEDIR='"/usr/local/share/locale"' 
> > -DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   
> > -g -O2 -c y.tab.c
> > ./parse.y: In function 'shell_getc':
> > ./parse.y:2399: error: label 'pop_alias' used but not defined
> > make: *** [y.tab.o] Error 1
> 
> There are a few cases like this that prevent a minimally-configured
> bash from building.  In this case, it's that there is a `goto pop_alias'
> but the pop_alias label is protected by an #ifdef.

I see bash has many tests to qualify the interpreter, could it not have
a similar thing for builds, a set of the most sensible configure/make
permutations that need to be passed after each patch ?
I'm not familiar enough to the code to offer anything sensible or I
would write some.


Another one, introduced in patch5 possibly? ... 

arm-softfloat-linux-gnu-gcc  -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"arm"' 
-DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"arm-unknown-linux-gnu"' 
-DCONF_VENDOR='"unknown"' -DLOCALEDIR='"/usr/local/share/locale"' 
-DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g 
-O2 -c variables.c
variables.c:4234: error: 'sv_tz' undeclared here (not in a function)
make: *** [variables.o] Error 1


Also from previous builds:

bash-4.2/bashline.c:2105: warning: Using 'endservent' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking

WTF ! Words fail me, I bet some c++ lover has made this mess for
me . I feel so old. take me back to 1986, a happy time 

Is it even possible to build a statically linked bash?
I've done it before but that was in the land time forget, around kernel
2.4.24, when gcc started with a "3." and worked :-( ggr

Thanks,
Jon

Re: Bash scripting and large files: input with the read builtin from a redirection gives unexpected result with files larger than 2GB.

[Jonathan Nieder]

Hi Chet,

Chet Ramey wrote:

> Compile and run the attached program.  If it prints out `4', which it does
> on all of the Debian systems I've tried, file offsets are limited to 32
> bits, and accessing files greater than 2 GB is going to be unreliable.

off_t is typedef'd to off64_t if you compile with -D_FILE_OFFSET_BITS=64.
The AC_SYS_LARGEFILE autoconf macro is supposed to cause bash to be
built with -D_FILE_OFFSET_BITS=64 (and seems to work that way here,
based on the result of "eu-readelf -s /bin/bash | grep open").

Jean-François is using a 64-bit architecture, where _FILE_OFFSET_BITS=64
is the default, anyway.

So I fear the problem is somewhere else.  (Maybe an "int" is used as an
offset somewhere.)

Hope that helps,
Jonathan

Broken 'test -x' behaviour for euid=0 on Solaris

[Jonathan Perkin]

The implementation-defined behaviour of access() and faccessat() on Solaris is
as follows:

If any access permissions are to be checked, each will be
checked individually,  as  described  in  Intro(2).  If  the
process has appropriate privileges, an implementation  may
indicate  success for  X_OK  even  if  none of the execute file
permission bits are set.

As such, 'test -x' performed as root will return true even for files
which are not executable:

  bash-4.2# uname -srvm
  SunOS 5.11 joyent_20120126T071347Z i86pc
  bash-4.2# echo $BASH_VERSION 
  4.2.42(1)-release
  bash-4.2# touch /var/tmp/foo
  bash-4.2# ls -l /var/tmp/foo
  -rw-r--r--   1 root root   0 Feb 28 14:13 /var/tmp/foo
  bash-4.2# test -x /var/tmp/foo
  bash-4.2# echo $?
  0
  bash-4.2# /bin/test -x /var/tmp/foo
  bash-4.2# echo $?
  1
  bash-4.2# 

There is already handling for this chosen behaviour within sh_eaccess(), so it
is simply a matter of extending it for the faccessat() case, as implemented in
the patch below (against current git from git://git.sv.gnu.org/bash.git):

diff --git a/lib/sh/eaccess.c b/lib/sh/eaccess.c
index 534c526..453e328 100644
--- a/lib/sh/eaccess.c
+++ b/lib/sh/eaccess.c
@@ -206,7 +206,12 @@ sh_eaccess (path, mode)
 return (sh_stataccess (path, mode));
 
 #if defined (HAVE_FACCESSAT) && defined (AT_EACCESS)
-  return (faccessat (AT_FDCWD, path, mode, AT_EACCESS));
+  ret = faccessat (AT_FDCWD, path, mode, AT_EACCESS);
+#  if defined(SOLARIS)
+  if (ret == 0 && current_user.euid == 0 && mode == X_OK)
+return (sh_stataccess (path, mode));
+#  endif
+  return ret;
 #elif defined (HAVE_EACCESS)   /* FreeBSD */
   ret = eaccess (path, mode);  /* XXX -- not always correct for X_OK */
 #  if defined (__FreeBSD__)

Chances are high that 'defined (__FreeBSD__)' should be added to this test too,
but I do not have any FreeBSD machines on which to verify this, so I have not
added it for now.

I have verified this fix on SmartOS, an illumos distribution.  As far as I am
aware, the faccessat() implementation has not diverged between illumos and
Solaris 11, but again I do not have access to a Solaris 11 system to verify
this for certain.

Regards,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com

Re: Broken 'test -x' behaviour for euid=0 on Solaris

[Jonathan Perkin]

* On 2013-02-28 at 19:13 GMT, Chet Ramey wrote:

> On 2/28/13 9:24 AM, Jonathan Perkin wrote:
>
> > There is already handling for this chosen behaviour within sh_eaccess(), so 
> > it
> > is simply a matter of extending it for the faccessat() case, as implemented 
> > in
> > the patch below (against current git from git://git.sv.gnu.org/bash.git):
> 
> Thanks for the report.  The code in the devel git branch looks like this:

Ah, apologies, I didn't realise 'master' was the release branch, and
indeed the 'devel' branch works as expected.

Sorry for the noise,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com

Re: Bug/limitation in 'time'

[Jonathan Nieder]

-bug-bash, +help-bash

Bruce Dawson wrote:

> Chris Down pointed that out. My loop now looks like this -- portable (I
> believe) and fast:
>
> BashCount() {
> for (( i = $1 ; i > 0 ; i-- )); do

Not actually portable to non ksh-based shells.  See
<http://unix.org/2008edition/> for hints.

Hope that helps,
Jonathan

Re: [bash] wait: specify that you can only wait for child PIDs

[Jonathan Nieder]

Hi,

Török Edwin wrote[1]:

> $ wait 1
> bash: wait: pid 1 is not a child of this shell
>
> The manpage of bash, dash and wait should mention that the PID has to be a 
> child of the shell.

How about this patch?  (Should be applicable to the "devel" branch by
saving this message in mbox format and applying with "git am --scissors".)

-- >8 --
Subject: bash.1: processes waited for by "wait" are children

Reported-by: Török Edwin 
---
Thanks,
Jonathan

[1] http://bugs.debian.org/714743

 doc/bash.1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/bash.1 b/doc/bash.1
index fb4795a..58da8ce 100644
--- a/doc/bash.1
+++ b/doc/bash.1
@@ -10071,7 +10071,7 @@ subsequently reset.  The exit status is true unless a
 is readonly.
 .TP
 \fBwait\fP [\fB\--n\fP] [\fIn ...\fP]
-Wait for each specified process and return its termination status.
+Wait for each specified child process and return its termination status.
 Each
 .I n
 may be a process

Variable casts from string to array but silently fails in reverse

[Jonathan Doull]

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
 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -Wall
uname output: Linux moriarty 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3
17:37:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

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

Description:

Variables can be automatically cast from string to array.
However when cast from array to string, the cast silently fails.

Repeat-By:

Demonstraction script:

#-SCRIPT START   ---
#!/bin/bash
function demonstrate_fail() {

local something

something=""  # setting something to a string
declare -p something

something=(hello world now)   # setting something to an array
declare -p something

something=""  # setting something to a string
declare -p something  # UNEXPECTED BEHAVIOUR : something is
still an array

something=1   # setting something to an integer
declare -p something  # UNEXPECTED BEHAVIOUR : first array
element is updated

}

demonstrate_fail
#-SCRIPT END   ---

Fix:
 Using unset seems only workaround.

Re: Variable casts from string to array but silently fails in reverse

[Jonathan Doull]

Thanks - understandable although was confusing at the time and made for a
nasty subtle scripting bug.

Bash is not for the faint hearted.


On 31 January 2014 19:45, Chet Ramey  wrote:

> On 1/31/14 10:39 AM, Jonathan Doull wrote:
>
> > Bash Version: 4.2
> > Patch Level: 25
> > Release Status: release
> >
> > Description:
> >
> > Variables can be automatically cast from string to array.
> > However when cast from array to string, the cast silently fails.
>
> Not quite.  The bash man page says:
>
> "Referencing an array variable without a subscript is equivalent to
> referencing the array with a subscript of 0."
>
> This works for both obtaining and assigning values.  So, you are partially
> correct: assigning to a variable using array assignment syntax converts
> it to an array.  However, once a variable has been converted to an
> array, references without subscripts are equivalent to ${array[0]} or
> array[0]=value.
>
> Chet
> --
> ``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/
>

Re: "[ -n ${emptyvariable} ]" returns success

[Jonathan Kamens]

On 09/20/2007 07:46 PM, Paul Jarc wrote:

[EMAIL PROTECTED] wrote:
  

foo=
[ -n ${foo} ] && echo true

Prints "true".


That's the correct behavior.
  
OK, thanks for the explanation.  It makes sense, although I think it's 
just a little gross. ;-)



To avoid pitfalls like this, always quote variable expansions.  The [[
command is also less tricky.
  
Yes, I know that, but the person who wrote the code in which I noticed 
this issue apparently does not :-).


Thanks again,

 jik

Command prompt disappears when working directory is one whose name ends in a '\' (backslash)

[Jonathan Plafker]

Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib   -g -O2
-Wall
uname output: Linux hp-ubuntu 2.6.24-18-generic #1 SMP Wed May 28 20:27:26
UTC 2008 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu

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

Description:
Command prompt disappears when working directory is one whose name ends
in a '\' (backslash)
Repeat-By:
Running the following command:
mkdir ./asdf\\ && cd ./asdf\\
Fix:
Probably has something to do with the way things are escaped in the
default $PS1.
Mine is '${debian_chroot:+($debian_chroot)[EMAIL PROTECTED]:\w\$' (without 
quotes),
and I haven't changed it, so I assume its the default.

strange 'delayed' aliases

[Jonathan Claggett]

Hi all,

I'm not sure if this is a bug or not but it certainly caught me by surprise.
I accidentally created an alias ending with a backslash and a newline today
and the resulting alias proceeded to grab the text on the line _after_ I ran
it. For example:

*$* echo $BASH_VERSION
4.0.33(1)-release
*$* alias x='echo \
*>* '
*$* x
*$* Hello, World!
Hello, World!
**
Is this delayed response expected?

Regards,
Jonathan

Re: strange 'delayed' aliases

[Jonathan Claggett]

>
> There is certainly unexpected behavior going on here.  I'll take a closer
> look, but fixes will have to wait until bash-4.2 (or a patch to bash-4.1
> if the problem is widespread).


4.2 would be fine but not before please! I'm still scheming how best put
this feature to "good" use in my "friend's" .bashrc in the near future ;-)

Typo in documentation

[Jonathan Simozar]

Hello,

On the page
http://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html,
in the section *${parameter%%word}*, there is a duplicate phrase in the
sentence

"If the pattern matches If the pattern matches a trailing portion of the
expanded value of parameter, then the result of the expansion is the value
of parameter with the shortest matching pattern (the ‘%’ case) or the
longest matching pattern (the ‘%%’ case) deleted. "

Shell exits after process substitution when using DEBUG trap with extdebug

[Jonathan Rascher]

$ bash --version
GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)

$ uname -a
Linux penguin 5.4.40-04224-g891a6cce2d44 #1 SMP PREEMPT Tue Jun 23 20:21:29
PDT 2020 x86_64 GNU/Linux

(This is a Pixelbook running the default Crostini Linux VM under Chrome
OS 84.0.4147.110. I can reproduce the issue on regular Debian too, though.)

To reproduce, run the following commands:

shopt -s extdebug
trap : DEBUG
: < <(:)

Now, type any character (e.g., 'a'). At this point, you'll see bash print
`exit`, and the shell does indeed exit. Additionally, assuming you ran bash
inside another shell, you'll see the 'a' character is echoed.

It's a hard to describe clearly, but the result looks like this
(`bcat@penguin:pts/0` is the prompt from my outer shell):

bcat@penguin:pts/0 J:0 ~
$ bash --norc
bash-5.0$ shopt -s extdebug
bash-5.0$ trap : DEBUG
bash-5.0$ : < <(:)
bash-5.0$ [I TYPED 'a' HERE]exit
bcat@penguin:pts/0 J:0 ~
$ a

The inner shell with the DEBUG trap acts as if it received an EOF on stdin,
and exits accordingly, but the 'a' character I typed into my terminal is
indeed still there, and it's echoed by the outer shell after the inner
shell (wrongly) exits. I wonder if stdin of the inner shell is getting
screwed up by the extdebug DEBUG trap somehow.

Cheers,
Jon

Re: Shell exits after process substitution when using DEBUG trap with extdebug

[Jonathan Rascher]

On Tue, Aug 4, 2020 at 9:20 AM Chet Ramey  wrote:

> On 8/3/20 9:44 PM, Jonathan Rascher wrote:
> > $ bash --version
> > GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
> >
> > $ uname -a
> > Linux penguin 5.4.40-04224-g891a6cce2d44 #1 SMP PREEMPT Tue Jun 23
> 20:21:29
> > PDT 2020 x86_64 GNU/Linux
> >
> > (This is a Pixelbook running the default Crostini Linux VM under Chrome
> > OS 84.0.4147.110. I can reproduce the issue on regular Debian too,
> though.)
> >
> > To reproduce, run the following commands:
> >
> > shopt -s extdebug
> > trap : DEBUG
> > : < <(:)
>
> Thanks for the report. I can't reproduce this with macOS, but I can with
> RHEL 7. I'll take a look.
>

Thanks!

The EOF hunch made me decide to see what happened with ignoreeof set. Sure
enough, instead of exiting when I type the first character after the
command with the process substitution, bash just prints `Use "exit" to
leave the shell.` And then the character I actually typed is still echoed
to the console, and I can keep using the shell. (It doesn't exit if
ignoreeof is set.)

Cheers,
Jon

Verifying behavior of nameref feature

[Jonathan Hankins]

I wanted to verify that this behavior is intended, as I can't find it
described in the manual.

$ echo $BASH_VERSION
4.3.30(1)-release
$ foo=bar
$ echo $foo
bar
$ bar=123
$ echo $bar
123
$ typeset -n foo
$ echo $foo
123
$ echo ${!foo}# this is what I want to verify
bar

Is using ${!foo} intended to yield the name of the var that foo references,
now that foo has been turned into a nameref?  I wanted to use this
functionality in a script, but wanted to make sure it was intentional
before I rely on it.

Thanks,

-Jonathan Hankins


-- 

Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us

Re: Interactive job control and looping constructs

[Jonathan Hankins]

If this behavior (ignore with warning one or more Ctrl-Z keypresses during
loops before eventually backgrounding) was desirable, there may be code
that could be borrowed from IGNOREEOF handling (I haven't looked at it).

-Jonathan Hankins

On Wed, Dec 31, 2014 at 1:26 PM, Ed Avis  wrote:

> Thanks for your reply.  I am glad to hear that this is already on the wish
> list,
> although I appreciate it is not straightforward to implement.
>
> A stopgap might be to make Ctrl-Z do nothing when the currently running
> command is a loop or other flow control construct.
> Instead it would print a message explaining that only the current
> subprocess would be interrupted, and saying to hit Ctrl-Z again if that is
> what you really wanted.  I hope this might go some way to making things
> less confusing, and be relatively quick to hack up.
>
> --
> Ed Avis 
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
>



-- 
----
Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us

Re: [bug-bash] Named fifo's causing hanging bash scripts

[Jonathan Hankins]

Dr. Fink,

Have you tried getting rid of the stderr redirect on your find command to
make sure find isn't showing any errors?

If you eliminate most of the inside of your while loop, does it still
hang?  For example:

while IFS="|" read link link_dir link_dest; do
echo "$link,$link_dir,$link_dest"
done < <(find . -type l -printf '%p|%h|%l\n' 2>/dev/null)

-Jonathan Hankins


On Fri, Jan 16, 2015 at 9:46 AM, Chet Ramey  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 1/16/15 10:32 AM, Dr. Werner Fink wrote:
> > On Fri, Jan 16, 2015 at 09:22:36AM -0500, Chet Ramey wrote:
> >> On 1/13/15 4:29 AM, Dr. Werner Fink wrote:
> >>
> >>>>> Bash Version: 4.3
> >>>>> Patch Level: 33
> >>>>> Release Status: release
> >>>>>
> >>>>> Description:
> >>>>> Named fifo's causing hanging bash scripts like
> >>>>>
> >>>>> while IFS="|" read a b c ; do
> >>>>>   [shell code]
> >>>>> done < <(shell code)
> >>>>>
> >>>>> can cause random hangs of the bash.An strace shows that
> the bash
> >>>>> stays in wait4()
> >>>>
> >>>> And when you attach to one of the hanging bash processes using gdb,
> what
> >>>> does the stack traceback look like?
> >>>
> >>> Yes (and sorry for the wrong email address as this was done on a clean
> virtual sysstem)
> >>>
> >>> there are two hanging bash processes together with the find command:
> >>>
> >>> werner   19062  0.8  0.0  11864  2868 ttyS0S+   10:21   0:00 bash
> -x /tmp/brp-25-symlink
> >>> werner   19063  0.0  0.0  11860  1920 ttyS0S+   10:21   0:00 bash
> -x /tmp/brp-25-symlink
> >>> werner   19064  0.2  0.0  16684  2516 ttyS0S+   10:21   0:00 find
> . -type l -printf %p|%h|%l n
> >>>
> >>> the gdb -p 19062 and gdb -p 19063 show
> >>>
> >>> (gdb) bt
> >>> #0  0x7f530818a65c in waitpid () from /lib64/libc.so.6
> >>> #1  0x0042b233 in waitchld (block=block@entry=1, wpid=19175)
> at jobs.c:3235
> >>> #2  0x0042c6da in wait_for (pid=pid@entry=19175) at
> jobs.c:2496
> >>
> >> What do ps and gdb tell you about pid 19175 (and the corresponding pid
> in
> >> the call to waitchld in the other traceback)?  Running, terminated,
> reaped,
> >> other?
> >
> >   d136:~ # ps 10942
> > PID TTY  STAT   TIME COMMAND
> >   d136:~ #
> >
> > ... the process does not exists anymore. I guess that this could belong
> to
> > the sed commands of the script.
>
> This is why I need to be able to reproduce it.  If the process got reaped,
> when would it have happened and why would the call to wait_for() have
> found a valid CHILD struct for it?  The whole loop runs with SIGCHLD
> blocked, so it's not as if the signal handler could have reaped the
> child out from under it.  I have questions but no way to find answers.
>
>
> - --
> ``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/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (Darwin)
>
> iEYEARECAAYFAlS5MjoACgkQu1hp8GTqdKvN5ACeK9XEiIQ1glUHC4hEF3ZTKJjL
> dUkAoI6nnxKypXP3MFns6/TyaOHNmHL5
> =x3Ck
> -END PGP SIGNATURE-
>
>


-- 

Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us

Re: If $HISTFILE is set to /dev/null and you execute more commands than $HISTFILESIZE, /dev/null is deleted.

[Jonathan Hankins]

A test with the POSIX S_ISREG macro on HISTFILE will determine if it, or
the file it points to in the case of a symlink, is a regular file.

Just looked through the source, and it looks like general.c:file_exists()
does not do any special handling of non-regular files, and
lib/readline/histfile.c:history_do_write() calls open() and rename() on
HISTFILE without checking if it is a non-regular file, which I imagine
could lead to various "bad things" in the case of pipes, char and block
devices, etc. such as what the OP pointed about about "/dev/null".

I haven't verified, but I think it also will not dereference links and may
potentially be made to clobber or otherwise mess with files ending in
hyphen (/etc/shadow-, /etc/passwd- and /etc/group- come to mind) because of
the way lib/readline/histfile.c:history_backupfile() constructs the backup
file name.  Someone with more knowledge than myself might want to look at
this closer.  It seems like it might be a vector for abuse.

-Jonathan Hankins

On Fri, Jan 30, 2015 at 9:06 AM, Greg Wooledge  wrote:

> On Fri, Jan 30, 2015 at 09:58:43AM -0500, Chet Ramey wrote:
> > On 1/30/15 4:36 AM, crocket wrote:
> > > It turns out that tramp on emacs 24.4 sets $HISTFILE to /dev/null and
> > > makes bash delete /dev/null when I kill emacs.
> > >
> > > When /dev/null is not a character device but a regular file, a lot of
> > > programs freeze.
> >
> > This indicates a permissions or file system problem.
>
> My guess was that (s)he's running bash as root, which accounts for the
> ability to delete /dev/null and recreate it as an ordinary file.
>
>


-- 

Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us

Re: If $HISTFILE is set to /dev/null and you execute more commands than $HISTFILESIZE, /dev/null is deleted.

[Jonathan Hankins]

I agree about being able to use named pipes, etc. as HISTFILE.  My concern
is that I think there may be a code path that leads to rename() and
open(O_TRUNC...) being called on something that isn't a regular file.
Furthermore, I think that if someone can manipulate a user's HISTFILE
setting maliciously, there may be a code path to cause an unwitting
overwrite of a file whose name ends in hyphen.

Specifically, if lib/readline/histfile.c:{append,write}_history() get
called, in turn history_do_write() is called, which results in an open with
append or a trunc, and when overwrite is set, a rename to HISTFILE + "-".
It doesn't look like the return value from rename(output, bakname) is
tested, and if the open() on HISTFILE fails, it does a rename(bakname,
output) to "restore" the backup, also not checking the return value from
rename().  I believe this could even do something bad such as renaming
/etc/shadow- to /etc/shadow, clobbering the current /etc/shadow, etc.
(assuming you are root).

Aside from the case where the user running bash is root, I think it's not
uncommon for users to have group write access to a variety of things in
/dev.

If I can get some time, I will play around with it over the weekend and see
if I can confirm my suspicions.

-Jonathan Hankins


On Fri, Jan 30, 2015 at 1:25 PM, Chet Ramey  wrote:

> On 1/30/15 2:09 PM, Jonathan Hankins wrote:
> > A test with the POSIX S_ISREG macro on HISTFILE will determine if it, or
> > the file it points to in the case of a symlink, is a regular file.
> >
> > Just looked through the source, and it looks like general.c:file_exists()
> > does not do any special handling of non-regular files, and
> > lib/readline/histfile.c:history_do_write() calls open() and rename() on
> > HISTFILE without checking if it is a non-regular file, which I imagine
> > could lead to various "bad things" in the case of pipes, char and block
> > devices, etc. such as what the OP pointed about about "/dev/null".
>
> Well, like always, it depends.  The current implementation allows a user
> to use a named pipe with a different program running to be a `history
> file'.  That flexibility can be valuable.
>
> I don't think that readline should be attempting to do backups of non-
> regular files, though.  The history file truncation code, which is called
> when HISTFILESIZE is changed, already rejects attempts to use non-regular
> files.
>
> --
> ``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/
>
>


-- 

Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us

Re: If $HISTFILE is set to /dev/null and you execute more commands than $HISTFILESIZE, /dev/null is deleted.

[Jonathan Hankins]

Doh - slow brain day - thanks for the correction.  That nullifies my
concern when user is not root, for part of the rename() issue.

I think the return values of rename() should be checked, and it
history_do_write() should not try to rename(bakname, output) unless it
actually did rename(output, bakname) successfully.  And with both rename()
calls, ERRNO should be reported to the user if they fail.

As far as open() on HISTFILE for append or truncate, when user is root (or
when user has owner or group write to the file), I think bash (readline?)
shouldn't overwrite, append to or rename non-regular files.

I also think the handling of the case where HISTFILE is a symlink may
misbehave (it would read the history in from the file the link refers to,
but on overwrite, replace the symlink, instead of the file it refers to.)

-Jonathan Hankins

On Fri, Jan 30, 2015 at 3:27 PM, Andreas Schwab 
wrote:

> Jonathan Hankins  writes:
>
> > Aside from the case where the user running bash is root, I think it's not
> > uncommon for users to have group write access to a variety of things in
> > /dev.
>
> Rename or delete requires write access to the containing directory.
>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>
>


-- 

Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us

Re: If $HISTFILE is set to /dev/null and you execute more commands than $HISTFILESIZE, /dev/null is deleted.

[Jonathan Hankins]

On Sat, Jan 31, 2015 at 4:40 PM, Chet Ramey  wrote:

> On 1/30/15 3:50 PM, Jonathan Hankins wrote:
> > I agree about being able to use named pipes, etc. as HISTFILE.  My
> concern
> > is that I think there may be a code path that leads to rename() and
> > open(O_TRUNC...) being called on something that isn't a regular file.
>
> OK, say the history file is not a regular file.  What negative scenarios
> are possible if the history library opens that file with O_TRUNC
>

​If the history code opens a block or char device file for append or
truncate, and writes to it, it could destroy the underlying file
structure.  I can't think of any reasonable scenario where HISTFILE could
be a block or char device, but like you said, named pipes could be useful.
Maybe test the file with S_ISREG|S_ISFIFO.
​


> > Furthermore, I think that if someone can manipulate a user's HISTFILE
> > setting maliciously, there may be a code path to cause an unwitting
> > overwrite of a file whose name ends in hyphen.
>
> If someone can manipulate a user's $HISTFILE setting, they can overwrite
> any file the user has permission to write.  It's always been thus.


​Right.  My concern is that a potential exploit could inject a malicious
value for HISTFILE into the environment.  I think (but may be wrong) that
HISTFILE is the only codepath in a default shell invocation that could
result in a silent writing to an arbitrary file without direct action on
the part of the user.  Good security practices are the responsibility of
the user, but I think it would be prudent to ensure that HISTFILE is, at
least a regular file, or a pipe.

-Jonathan Hankins


-- 

Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us

Re: Does [ -f FILE ] have a bug on testing a symlink ?

[Jonathan Hankins]

$ touch foo
$ ln -s foo bar
$ [[ -f foo ]] && [[ ! -h foo ]] && echo "exists and is not a symlink"
exists and is not a symlink
$ [[ -f bar ]] && [[ ! -h bar ]] && echo "exists and is not a symlink"
$

-Jonathan Hankins

On Mon, Feb 9, 2015 at 6:00 PM, Cheng Rk  wrote:

>
>
> On Monday, February 9, 2015 3:13 PM, Andreas Schwab 
> wrote:
> Cheng Rk  writes:
>
> >> Then the builtin test help need a documentation fix, right?
>
> You're addressing different lines but I am saying this line is inaccurate,
> right?
>
>
> -f FILETrue if file exists and is a regular file.
>
>
> Is there really a simple regular file test existing?
>
>
>
> > test: test [expr]
> Evaluate conditional expression.
>
> Exits with a status of 0 (true) or 1 (false) depending on
> the evaluation of EXPR.  Expressions may be unary or binary.  Unary
> expressions are often used to examine the status of a file.  There
> are string operators and numeric comparison operators as well.
>
> The behavior of test depends on the number of arguments.  Read the
> bash manual page for the complete specification.
>
>


-- 

Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us

Re: Does [ -f FILE ] have a bug on testing a symlink ?

[Jonathan Hankins]

The OP's issue isn't bash-specific.

The behavior of test WRT symbolic links is specified in POSIX, cf.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

Specifically:

"With the exception of the -h pathname and -L pathname primaries, if a
pathname argument is a symbolic link, test shall evaluate the expression by
resolving the symbolic link and using the file referenced by the link."

-Jonathan Hankins

On Tue, Feb 10, 2015 at 3:25 PM, Stephane Chazelas <
stephane.chaze...@gmail.com> wrote:

> 2015-02-09 14:59:06 -0700, Bob Proulx:
> [...]
> > The idea is that symlinks should be completely transparent and
> > invisible to most applications.  The idea is that when normal things
> > are run they don't realize they are using a symlink.  Behavior would
> > be exactly the same as if it were a regular file system link.  That is
> > what is happening in your test case.  The symlink references an
> > existing file, is a regular file and exists, therefore the status is
> > true.
> [...]
>
> Note the discrepancy with "find" though.
>
> With find, -type f will not match on symlinks to regular files
> (unless you also use -L/-follow).
>
> If you actually want to find regular files after resolving
> symlinks, without resolving symlinks when walking down the
> directory tree, that's where it becomes cumbersome.
>
> POSIXly, you have to resort to the test command:
>
> find . -exec test -f {} \; -print
>
> With GNU find, you can use -xtype:
>
> find . -xtype f
>
> GNU find's -printf still doesn't give information on the target
> of  the symlink.
>
> --
> Stephane
>
>


-- 

Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us

dead link

[Jonathan Hadida]

Hi there

There is a dead link in the online bash manual for shopt: 
http://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html
[promptvars] "Controlling the Prompt" should point to 
http://www.gnu.org/software/bash/manual/bashref.html#Controlling-the-Prompt
It currently points to 
http://www.gnu.org/software/bash/manual/bashref.html#Controlling-the-Prompt, 
which yields a 404


Cheers, J

Re: Feature Request re: syslog and bashhist

[Hankins, Jonathan]

Maybe OT, but there is software to hook exec at the system library level
and provide syslog auditing: https://github.com/renard/snoopylogger

-Jonathan Hankins

On Thu, Sep 3, 2015 at 2:43 PM, Chet Ramey  wrote:

> On 9/3/15 2:43 AM, Ondrej Oprala wrote:
>
> > We have recently had a customer request for this, and Steve Grubb
> corrected
> > the original patch for auditing. IIRC, aureport-2.4.2 should be able to
> > handle the USER_TTY
> > events now. With his permission, I'm attaching the new patch.
>
> Thanks for the update.
>
> Chet
> --
> ``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/
>
>


-- 

Jonathan HankinsHomewood City Schools

The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan

jhank...@homewood.k12.al.us


-- 
This e-mail is intended only for the recipient and may contain confidential 
or proprietary information. If you are not the intended recipient, the 
review, distribution, duplication or retention of this message and its 
attachments is prohibited. Please notify the sender of this error 
immediately by reply e-mail, and permanently delete this message and its 
attachments in any form in which they may have been preserved.

Double slash root cwd

[Jonathan Ździarski]

Hey there-

Noticed in bash you can cd into paths prefixed with double slash; e.g. “cd 
//usr/sbin” and it will set the pwd environment variable as such; not sure if 
this was intended or not, but can see where some poor guy’s aliases or bash 
scripts are likely to barf.

Jonathan

Re: Double slash root cwd

[Jonathan Zdziarski]

Cool... thanks!

Pardon teh spellnig; Sent form my iPhone

> On Dec 11, 2016, at 4:55 PM, Chet Ramey  wrote:
> 
>> On 12/11/16 4:10 PM, Jonathan Ździarski wrote:
>> Hey there-
>> 
>> Noticed in bash you can cd into paths prefixed with double slash; e.g. “cd 
>> //usr/sbin” and it will set the pwd environment variable as such; not sure 
>> if this was intended or not, but can see where some poor guy’s aliases or 
>> bash scripts are likely to barf.
> 
> Posix requires it.  Look at the Bash FAQ, question E10, or one of the
> previous bug-bash discussions, such as
> 
> https://lists.gnu.org/archive/html/bug-bash/2011-08/msg00294.html
> 
> 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: history vs. poweroff

[Hankins, Jonathan]

This is discussed a bit here, along with a common pain point for
tmux/screen users:

https://news.ycombinator.com/item?id=10164053

zsh gets around both issues with a variety of options to have a synchronous
and interleaved history file.

-Jonathan Hankins

On Tue, Jan 31, 2017 at 1:40 PM Greg Wooledge  wrote:

> On Wed, Feb 01, 2017 at 03:31:57AM +0800, ? Dan Jacobson wrote:
> > GW> Log out, log back in as root, issue the command, and accept that
> root's
> > GW> (very short) shell history will be lost.
> >
> > Well mention that on the man page.
> > I.e., the man page should address the paradox of saving a complete
> > history vs. being able to turn off one's computer.
>
> I do not believe that it is bash(1)'s job to teach basic Unix system
> administration.
>
>

-- 
This e-mail is intended only for the recipient and may contain confidential 
or proprietary information. If you are not the intended recipient, the 
review, distribution, duplication or retention of this message and its 
attachments is prohibited. Please notify the sender of this error 
immediately by reply e-mail, and permanently delete this message and its 
attachments in any form in which they may have been preserved.