Bash – Why does ls .* show different files than ls ./.*

bashwildcards

Blank file .ignoramus in current directory exists.

bojan@localhost:~$ echo $GLOBIGNORE
.ignoramus
bojan@localhost:~$ ls .* | grep ignor
bojan@localhost:~$ ls ./.* | grep ignor
./.ignoramus

tools used
ls (GNU coreutils) 8.23
GNU bash, version 4.3.42(1)-release (x86_64-pc-linux-gnu)

Best Answer

The $GLOBIGNORE setting is processed by the shell when it expands the wildcard in your command line. In your first case, the shell first expands .* to .ignoramus, which is matched by $GLOBIGNORE, so it is not included in the names passed to ls.

In your second case, the shell expands ./.* to ./.ignoramus, which is not matched by $GLOBIGNORE. If you set $GLOBIGNORE to .ignoramus:./.ignoramus then the behaviour of your second command will match your first.

Related Solutions

Bash: I broke [[ < ]]

From the bash man page.

When used with [[, the < and > operators sort lexicographically using the current locale.

From the output, it appears to be working as designed.

Bash – Why is a zombie waiting for its child

The zombie isn't waiting for its child. Like any zombie process, it stays around until its parent collects it.

You should display all the processes involved to understand what's going on, and look at the PPID as well. Use this command line:

ps -t $(tty) -O ppid,pgid

The parent of the process you're killing is cat. What happens is that bash runs the background command cat <( sleep 100 & wait ) in a subshell. Since the only thing this subshell does is to set up some redirection and then run an external command, this subshell is replaced by the external command. Here's the rundown:

The original bash (12126) calls fork to execute the background command cat <( sleep 100 & wait ) in a child (14247).
- The child (14247) calls pipe to create a pipe, then fork to create a child to run the process substitution sleep 100 & wait.
  - The grandchild (14248) calls fork to run sleep 100 in the background. Since the grandchild isn't interactive, the background process doesn't run in a separate process group. Then the grandchild waits for sleep to exit.
- The child (14247) calls setpgid (it's a background job in an interactive shell so it gets its own process group), then execve to run cat. (I'm a bit surprised that the process substitution isn't happening in the background process group.)
You kill the grandchild (14248). Its parent is running cat, which knows nothing about any child process and has no business calling wait. Since the grandchild's parent doesn't reap it, the grandchild stays behind as a zombie.
Eventually, cat exits — either because you kill it, or because sleep returns and closes the pipe so cat sees the end of its input. At that point, the zombie's parent dies, so the zombie is collected by init and init reaps it.

If you change the command to

{ cat <( sleep 100 & wait ); echo done; } &

then cat runs in a separate process, not in the child of the original bash process: the first child has to stay behind to run echo done. In this case, if you kill the grandchild, it doesn't stay on as a zombie, because the child (which is still running bash at that point) reaps it.

Best Answer

Related Solutions

Bash: I broke [[ < ]]

Bash – Why is a zombie waiting for its child

Related Question