When I'm inside a running tmux installation and run a command that errors out, sometimes tmux will replace the name of the original command.

ie. if test is a directory, then this happens:

jameswright in ~ at portal1 via ⬢ v12.13.0           
➜ rm test                                     
tmux: cannot remove ‘test’: Is a directory

Note this behavior doesn't occur when using cp or ls. This is on Linux using Zsh. The issue does not occur when using Bash and in .tmux.conf, neither default-command nor default-shell are set.

However, if I prefix the command with env -i — as in env -i rm test — I am properly seeing rm as the command and not tmux:

➜ env -i rm test
rm: cannot remove 'test': Is a directory

Also, if I use strace to try and debug the problem -- using strace -fostrace.out rm test-- I am also correctly seeing rm instead of tmux:

➜ strace -fostrace2.out rm test
rm: cannot remove 'test': Is a directory

Any ideas as to how this could happen?

I assume the error message should be generated by the offending command, but this appears to say otherwise.

Running /bin/rm test — using the full binary path — has the same result as above.

Also, rm --help also replaces rm with tmux:

➜ rm --help
Usage: tmux [OPTION]... FILE...
Remove (unlink) the FILE(s).

  -f, --force           ignore nonexistent files and arguments, never prompt
To remove a file whose name starts with a '-', for example '-foo',
use one of these commands:
  tmux -- -foo

  tmux ./-foo
  • Is rm a regular binary executable? or a wrapper script? or a function? Or a builtin in your particular shell? What shell are you using? May 9, 2020 at 15:01
  • I'm not sure whether rm is a binary. rm is aliased to rm -i and where rm returns /bin/rm. I'm using zsh. May 9, 2020 at 18:05
  • @KamilMaciorowski Just as a test, I tried to replicate using bash instead of zsh and I don't see the same behavior (so the error returns rm: cannot remove 'test': Is a directory) May 9, 2020 at 18:06
  • @KamilMaciorowski Done. See edit. I'm not sure how definitely check whether rm is from GNU coreutils or not, but the man page for rm is at least from GNU coreutils 8.23 May 9, 2020 at 22:29
  • @Nicholas Marriott I've answered your questions in the edit. May 9, 2020 at 22:35

2 Answers 2


The issue was that the ARGV0 environment variable to tmux. In this case, it is the tmux AppImage that is setting the variable.

According to AppImage Documentation, the $ARGV0 variable is set to the name/path called to execute the AppImage. So running tmux will set ARGV0=tmux.

However, starting tmux using the absolute path to the AppImage /users/jameswright/.local/bin/tmux gives:

➜ rm test
/users/jameswright/.local/bin/tmux: cannot remove ‘test’: Is a directory

An immediate fix to this to run unset ARGV0 while in the tmux session.

This issue was fixed in the tmux AppImage repository. Otherwise, extracting the AppImage and calling the extracted binary itself will also fix the issue.


I don't see anything obvious in the rm source. It is interesting that it doesn't happen in bash.

See if you can reproduce by running:

/bin/rm test

Which will definitely rule out any wrapper scripts or aliases.

If it still happens, you could install strace and run, for example:

strace -fostrace.out rm test

And you may be able to look at strace.out and see if it is being passed tmux as its first argument (I think it is the first few lines).

Also perhaps check if rm --help shows tmux as well.

Another thing worth checking is: env -i rm test to rule out any environment variable causing trouble.

  • Progress! See edit 2, but env -i did fix the problem. Now to track down the guilty variable... May 9, 2020 at 23:45
  • Much like your other two deleted “answers” — this one and this other one — this is not an answer at all. This is simply a comment asking for clarification. May 9, 2020 at 23:59
  • @JamesWright It's probably not about a variable. It's about who's calling rm and providing argv[0] for it. It looks like env does it right and zsh doesn't. I think zsh tries to "improve" rm (compare this), so maybe calling rm is a special case, special piece of code, and there's a bug in the procedure. May 9, 2020 at 23:59
  • @KamilMaciorowski If I start another zsh login (zsh -l) the issue no longer appears. Any debugging tips would be helpful. Not zsh options I can see are relevant in this case. May 10, 2020 at 0:30
  • kamil-maciorowski's link is a good find, it does seem like zsh is messing with rm here and getting it slightly wrong. Are you saying it happens if you do zsh -l but not if you start zsh the way you normally do? You may have to ask the zsh developers or wait and see if a zsh expert comes along. May 10, 2020 at 9:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.