awesomeWM / awesome

awesome window manager
https://awesomewm.org/
GNU General Public License v2.0
6.39k stars 597 forks source link

Run-prompt should substitute ~ for home directory #1609

Open Veltas opened 7 years ago

Veltas commented 7 years ago

Output of awesome --version:

awesome v4.0 (Harder, Better, Faster, Stronger)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • RandR 1.5 support: ✔
 • LGI version: 0.9.1

How to reproduce the issue:

Run a program with Mod4+R, using tab-completion to run a program with a file in my home directory.

Actual result:

Program does not open given path.

Many programs won't try to open a file from your home directory if you give ~, which is what awesome currently does, for example mupdf: your shell would usually do this itself on the command line.

Expected result:

Program shouldn't be given the ~, especially since awesome tab-completes files from home directory, it should know better and substitute ~ for os.getenv("HOME") at the very least. This used to happen in awesome, and was since changed (to give prettier output I presume, since previously tab-completing would remove the ~ and replace with your home directory in-place in the run prompt).

Specifically an unquoted word starting with ~ should substitute ~ for os.getenv("HOME"). If ~username is replaced with username's home directory that's a bonus.

aviau commented 5 years ago

I agree! The prompt should eithier support ~ or stop tab-completing for it.

I want to add that I would like to configure other env variables for the promptbox, perhaps even aliases.

I have a number of aliases and scripts in ~/bin and I find it annoying that I cannot use them with my awesome prompt.

Maybe I should be able to specify in what shell awesome runs the command? For example I could have the commands ran in bash with my ~/.profile and everything else.

psychon commented 5 years ago

This used to happen in awesome, and was since changed

Do you know details on when this changed? Are you sure it was a change in awesome, or could it also be a change in e.g. bash or bash-completion?

Awesome does not actually do its own tab completion. It starts a shell (either bash or zsh) to do the completion and then just uses the results. This is why things like ~/f get completed with files in the home directory, but then actually running the command does not handle all that "shell magic". However, I do not see anything in awful.completions history that would suggest that ~ should no longer be expanded.

Quick idea on a fix: Change awful.widget.prompt to use spawn.with_shell instead of just plain spawn.

Edit: Okay, might be a side effect of 4c792b49a977b8b4ae1830996e691e72235ce0ac (which means that ~ is not expanded in the first word, but only later in the arguments and that is indeed the behaviour that I see). CC @blueyed