The usage of `cd builtins && $(MAKE) ...`

[Peng Yu]

Hi,

I see things like `cd builtins && $(MAKE) ...` in the Makefiles in
bash source code. GNU Make has the option of -C for entering a
directory and make. Is the reason to cd then make for compatibility
with other make's that don't support -C? Thanks.

-- 
Regards,
Peng

Re: The usage of `cd builtins && $(MAKE) ...`

[Vladimir Marek]

Hi,

> I see things like `cd builtins && $(MAKE) ...` in the Makefiles in
> bash source code. GNU Make has the option of -C for entering a
> directory and make. Is the reason to cd then make for compatibility
> with other make's that don't support -C? Thanks.

I'm afraid that you are in wrong mailing list. I'm putting this list on
bcc. You can consider asking at one of autotools lists

https://www.lrde.epita.fr/~adl/autotools.html

I would choose automake one. But yes, I believe that it's because not
every make clone has -C.

Cheers
-- 
Vlad

"COMMAND 2>&1 > PATH" doesn't work

[Dušan Kreheľ]

Hello.

If I try in bash this command ex. "rmdir somethingA > somethingA.out
2>&1" work right. But, if I try "rmdir somethingB 2>&1 >
somethingB.out" that work wrong.

That work's wrong in Bash version 4.4.23(1) and too in 5.0.0(1)-rc1:

# v. 4.4.23(1) #

$ mkdir /dev/shm/test
$ cd /dev/shm/test
$ rmdir somethingA > somethingA.out 2>&1
$ rmdir somethingB 2>&1 > somethingB.out
rmdir: failed to remove 'somethingB': No such file or directory
$ cat somethingA.out
rmdir: failed to remove 'somethingA': No such file or directory
$ cat somethingB.out
$ bash --version
GNU bash, version 4.4.23(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2016 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.
$


# 5.0.0(1)-rc1 #

$ cd bash-5.0-rc1/
$ ./bash
$ echo $BASH_VERSION
5.0.0(1)-rc1
$ mkdir /dev/shm/test
$ cd /dev/shm/test
$ rmdir somethingA > somethingA.out 2>&1
$ rmdir somethingB 2>&1 > somethingB.out
rmdir: failed to remove 'somethingB': No such file or directory
$ cat somethingA.out
rmdir: failed to remove 'somethingA': No such file or directory
$ cat somethingB.out
$

Dušan Kreheľ

Re: "COMMAND 2>&1 > PATH" doesn't work

[Eduardo A . Bustamante López]

On Sun, Dec 30, 2018 at 10:10:42PM +0100, Dušan Kreheľ wrote:
> Hello.
> 
> If I try in bash this command ex. "rmdir somethingA > somethingA.out
> 2>&1" work right. But, if I try "rmdir somethingB 2>&1 >
> somethingB.out" that work wrong.
> 
> That work's wrong in Bash version 4.4.23(1) and too in 5.0.0(1)-rc1:

Why do you expect these two to behave in the same way? They are clearly
distinct operations.


 COMMAND >FILE 2>&1

is not the same as:

 COMMAND 2>&1 >FILE

The order of redirections matter, they are processed left-to-right. Let's look
at these examples in more detail.


Example 1.

 COMMAND >FILE 2>&1

Let's break it down into tokens and see what happens at each step.

a) COMMAND

file descriptor 0 -> terminal
file descriptor 1 -> terminal
file descriptor 2 -> terminal

This is the "normal" state in an interactive shell, the three standard file
descriptors (input: 0, output: 1, and error: 2) are pointing to the terminal
device.

b) >FILE

file descriptor 0 -> terminal
file descriptor 1 -> FILE
file descriptor 2 -> terminal

The `>FILE' redirection is processed, causing file descriptor 1 (standard
output) to be directed to the file named `FILE'.

c) 2>&1

file descriptor 0 -> terminal
file descriptor 1 -> FILE
file descriptor 2 -> FILE

The `2>&1' redirection is processed, causing file descriptor 2 (the `2>' bit) to
be directed to "wherever-fd1-points-to" (i.e. the `&1' bit). FD1 currently
points to `FILE', so FD2 is updated to point to `FILE' too.


VS

Example 2.

 COMMAND 2>&1 FILE 

a) COMMAND

file descriptor 0 -> terminal
file descriptor 1 -> terminal
file descriptor 2 -> terminal

same as example 1.

b) 2>&1

file descriptor 0 -> terminal
file descriptor 1 -> terminal
file descriptor 2 -> terminal * no change

The `2>&1' redirection is processed, causing file descriptor 2 to be directed to
"wherever-fd1-points-to". FD1 currently points to the terminal. FD2 points to
the terminal too, so it stays the same.

c) >FILE

file descriptor 0 -> terminal
file descriptor 1 -> FILE
file descriptor 2 -> terminal

The `>FILE' redirection is processed, causing file descriptor 1 (standard
output) to be directed to the file named `FILE'.



So, this is not a bug. It's the expected behavior of redirections. If you want
to read more about it, I recommend:

- https://mywiki.wooledge.org/BashFAQ/055
- 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07

Re: bug in dirname loadable?

[Peng Yu]

On Wed, Dec 26, 2018 at 11:35 AM Chet Ramey  wrote:
>
> On 12/24/18 10:35 PM, Peng Yu wrote:
> > dirname loadable gives the following error. I think the coreutils'
> > direname's convention is better. Should it be considered as a bug to
> > fix?
> >
> > $ dirname -- -a
> > dirname: usage: dirname string
> > $(type -P dirname) -- -a
> > .
>
> Yes, dirname should skip over a `--' denoting the end of options. Thanks
> for the report.

There is a similar problem in `basename`. Is it due to a common bug on
how loadables are programmed?

$ builtin basename -a
-bash: basename: -a: invalid option
basename: usage: basename string [suffix]
$ builtin basename -- -a
--

-- 
Regards,
Peng

Reading from a file by using its FD returns its contents only once

[mike b]

Configuration Information:
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../. -I.././include -I.././lib  -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-7fckc0/bash-4.4=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie
-Wno-parentheses -Wno-format-security
uname output: Linux debian9 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2
(2018-10-27) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 12
Release Status: release

I am not quite sure if this is a bug, but here's what I find as a bit odd
behavior:

# modprobe zram num_devices=0
# exec {add}./t
# exec 10<./t
# read -r <&10
# echo $REPLY
bla
# read -r <&10
# echo $REPLY

#
Playing with something like:
# zram=/sys/class/zram/control/hot_add
# c=0; while  ((++c <= 3)); do read -r; echo "${REPLY:-NULL}"; done <"$zram"
0
NULL
NULL
#
also gets same results. In contrast to:
# c=0; while (( ++c <= 3 )); do read -r; echo "out: ${REPLY:-NULL}"; done
foo
out: foo
foo
out: foo
foo
out: foo
#
which keeps reading from default stdin (terminal in this case) without any
hiccups (as expected).

So, considering all the above, any hints on why subsequent reads in these
scenarios don't get any data from a file would be really appreciated. :)

Same behavior is seen in 4.3.30 and 5.0 versions.