bash: __ash_precmd: command not found

[menzel]

I often use a command to open another terminal in the same directory as the current one:
alias fork='urxvt &'

However, if I use this command together with ash I get the error message bash: __ash_precmd: command not found; everytime I run a command.

[barabo]

I can see how that would be annoying!

First, you should be able to temporarily disable the history logger by setting the environment variable: ASH_DISABLED=1 while it's happening.

Next, I would like you to try changing your alias to fork='env -i urxvt'. This should cause each new terminal to spawn in a new shell environment, forcing a fresh load of the history shell code. Without this, I believe your local environment is being copied in the new window and the shell code believe it's already been sourced. By giving your new terminal a clean environment, this should be prevented.

Also, I'm wondering if your current workflow behaves the way I think it does. Suppose you execute 'fork' within terminal A to create a new terminal B. Now, if you close terminal A, does it not also close terminal B? Is that desired? If not, you might change your alias to be fork='setsid urxvt'. This should spawn a new terminal in a clean environment that also will remain open when you close the parent terminal. However, I can't easily confirm at the moment because I'm using OSX and OSX does not include the setsid command.

Hope this helps!

[menzel]

Many thanks for your quick reply.
Setting the ASH_DISABLED variable did not have any effect on the newly spanwed terminals.

Running urxvt with env did not work and gave me the following error:

No protocol specified
urxvt: can't open display :0, aborting.

Running 'setsid urxvt' opened up a new terminal, the error message about __ash_precmd is still showing up on every command.

The 'child' terminal B does not close if I close terminal A. I can follow your argument on that, B should close, however it doesn't (and since it worked the whole time I never thought about that, but you are right that this is somewhat strange behaviour).

I think the issue lies on my side and my configuration, not your code, but I will reply here if I can find a solution.

Thanks again.

[sjjf]

This is the same as my issue #4 - the ASH_* variables and PROMPT_COMMAND value are exported, but the _ash* functions aren't - child bash processes see the environment set up for ash, but they don't see the functions that are needed to actually /run/ ash.

Starting a new terminal with a totally new login session will run ash correctly, but in most environments that'll lose a bunch of other stuff that might be essential - X session auth tokens (your display issue), SSH_AGENT settings, and so on. ASH_DISABLED is referenced within the functions, which aren't available in the child processes, so setting it won't make any difference.

As it stands, starting a new xterm/urxvt/gnome-terminal/whatever from the desktop environment /should/ work (and does with my gnome-terminal setup) - it'll create a whole new session, since it'll start from the base environment that your desktop set up, and unless you're doing something odd that won't include the ASH_* environment variables. But starting one from within an existing terminal session will run into this problem.