interactive shell can't find dgsh-conc

[mrmonkington]

(I can't really find any documentation about running dgsh interactively, so apologies if this isn't supported!)

I have a simple test program I entered interactively after invoking dgsh --login.

$ echo "hi" |\
tee |\
{{
cat

sed 's/hi/hello/'
}} |\
cat

With output:

dgsh-conc: command not found
dgsh-conc: command not found

dgsh does not return and I have to SIGINT it.

Run as a script:

$ cat test.dgsh 
#!/usr/bin/env dgsh

echo "hi" |
tee |
{{
    cat

    sed 's/hi/hello/'
}} |
cat

...it's fine and outputs:

hi
hello

The dgsh binary dependencies (including dgsh-conc are in /usr/local/libexec/dgsh as per default install configuration.

I'm using Ubuntu 17.04 with bash 4.4.7, and I built dgsh from master@e49dd7e4a6015c4ac6dfd0516284f7aa60fbffb8 (latest as of today)

[mfragkoulis]

In my environment, a system running Debian Jessie, the interactive command runs fine.

Did you perform a standard installation of dgsh? Could you tell me what dgsh --version outputs?

I'll perform a fresh installation on Ubuntu and see what happens.

[mrmonkington]

It was a standard installation as far as I can tell.

git clone --recursive https://github.com/dspinellis/dgsh.git
sudo apt install make automake gcc libtool pkg-config texinfo help2man check gperf wbritish wamerican libfftw3-dev csh graphviz gettext
make config
make
sudo make install

Oh except this is not what I expected:

mark@quiche:~ $   dgsh --version
GNU bash, version 4.3.46(2)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
mark@quiche:~ $ bash --version
GNU bash, version 4.4.7(1)-release (x86_64-pc-linux-gnu)
Copyright © 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

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

(Different versions)

Does that help?

Thanks!

[mfragkoulis]

The different versions are OK; we will soon merge Bash's latest upstream changes.

I tried the interactive script on Debian Jessie, FreeBSD 11.0, Mac OS X 10.12.6, and Ubuntu server 16.04 and 17.04, but the command ran successful on all those environments.

Could the bug have to do with your specific setting? Could you retry installing dgsh on a vanilla system?

[lucaswerkmeister]

I seem to have the same problem. I played around with it for a bit, and found that if I launch dgsh with --norc, dgsh-conc is found without problems – and as long as I do some dgsh stuff before, I can even source the rc files and dgsh continues to work. That is:

• dgsh --norc, dgsh commands: works
• dgsh --norc, dgsh commands, . /etc/profile ~/.bashrc, more dgsh commands: works
• dgsh --norc, . /etc/profile ~/.bashrc, dgsh commands: doesn’t work

This feels like it might be because dgsh-concat is hashed. Perhaps @mrmonkington and I have stuff in our profiles that overwrites PATH instead of appending/prepending to it? (Though I wasn’t able to find anything like that in my profile files.)

[dspinellis]

That's good observation, thank you! Dgsh does some sneaky behind-the-scenes processing of the path in order to transparently replace dgsh-capable commands for the normal ones only when these commands are executed in a multipipe context. It could be that something in your path causes this processing to fail. Can you share your paths in this issue?

[lucaswerkmeister]

Sure! The PATH with --norc is:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/home/$USER/.local/bin

After sourcing /etc/profile /etc/bash.bashrc ~/.bashrc, :/snap/bin is appended to the end, with no other change.

[mrmonkington]

I can confirm --norc works around the problem.

My usual PATH (has a few duplicates):

/usr/local/sbin:/usr/local/sbin:/home/mark/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

my PATH with --norc

/usr/local/sbin:/home/mark/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

However if I explicitly set the path to the --norc form at the end of my .bashrc it doesn't fix things.

[dspinellis]

Can you please try the wrong-path branch of bash?

[mrmonkington]

(this one? https://github.com/mfragkoulis/bash/tree/wrong-path)

Sorry didn't help :-( Though I enjoyed learning that there is a bash function called stupidly_hack_special_variables!

(To confirm, I switched dgsh/unix-tools/bash to the wrong-path branch, make clean, make, make install.)

I think it's something to do with an environment include for libvte. Tilix (my terminal) asks that I explicitly run this per shell (not just in login shells):

• https://github.com/GNOME/vte/blob/master/src/vte.sh

(It's discussed here https://github.com/gnunn1/tilix/wiki/VTE-Configuration-Issue)

If I stop that happening dgsh works fine.

Apologies, I should have realised that was non-standard earlier and mentioned it!

[dspinellis]

Thank you for the swift and comprehensive feedback. So, roughly,under Tilix and libvte dgsh is always run as a login shell and this configures its path to be that of bash rather than dgsh. Shall we close this issue, or is there a way to fix this behavior?

[dspinellis]

No response from reporter; closing the issue.

[mrmonkington]

Apologies I've been out of office for a few days.

My terminal does not run as a login shell, I simply source /etc/profile.d/vte.sh in my .bashrc in order to configure PROMPT_COMMAND (which affects Gnome Terminal and any other libvte terminals that want to report pwd, etc, in their title bars and/or spawn new terminals/splits in the correct directory). vte.sh does not seems to touch PATH.

In other words, you can replicate this problem by running:

dgsh
source /etc/profile.d/vte.sh # possibly vte-2.91.sh on your system

Not sure if that means you want to re-open the bug?

[dspinellis]

I've isolated the problem to sourcing the following minimal script:

false || return 0

and then executing interactively

{{ echo hi ; echo there ; }} | cat

After this gets sourced by dgsh the problem is reproduced.

@mfragkoulis any idea?

If not, when can compare the strace -f dgsh output with and without running the script.

[dspinellis]

System calls under normal execution

17981 stat64("/home/dds/libexec/dgsh/dgsh-conc", {st_mode=S_IFREG|0755, st_size=113088, ...}) = 0
[...]
17982 execve("/home/dds/libexec/dgsh/dgsh-conc", ["dgsh-conc", "-i", "2"], [/* 31 vars */] <unfinished ...>

System call under the failed execution

18012 stat64("/usr/local/bin/dgsh-conc", 0xbfa55a3c) = -1 ENOENT (No such file or directory)

[dspinellis]

Even simpler, executing the following script

true || false
dgsh-enumerate 2 | cat

fails as follows

$ dgsh t.sh
t.sh: line 2: dgsh-enumerate: command not found

[dspinellis]

Looking at the debug output it is obvious that dgsh is set to 0 and never set back.

8351: A non-dgsh connector is used in this command.
8351: Set dgsh=0 in order to fall back to bash.