Closed chevdor closed 9 months ago
uh ok, this link is a gold mine :)
That also provides options to https://github.com/Nukesor/pueue/issues/451
While convenient, it is not very convenient to have to refening all aliases just for pueue though.
This was already a feature in the old pueue implementation and it was a constant pain point, since there's no good way to implement aliases. These are the current constraints:
/bin/sh
..bashrc
files. These often contain logic such as plugins that require an interactive shell and break in a non-interactive environment.
-> This would break the shell for a majority of users.
.bashrc
that only contains aliases, which is basically the same as the pueue_aliases.yml
right now.As I said earlier, this was implemented in the first version of pueue, but users entered broken states they didn't understand and that simply couldn't be fixed by any upstream changes, since these were shell specific problems.
I'm still very hesitant to allow any custom shell specific logic (or even custom shells) to be executed, unless there's a very good way of handling this.
A few fun questions from the top of my head:
.rc
file than the client, how should that be handled? The user most likely expects the local .rc file to be used for executing programs..*rc
file locationsI understand, thanks for the explanations.
How about parsing ~/.bash_aliases
and/or ~/zsh_aliases
. Those are standard and could easily be parsed with a regex.
To answer your questions:
If the daemon is on a remote machine or a different user, and has a different .rc file than the client, how should that be handled? The user most likely expects the local .rc file to be used for executing programs.
Pick one of the \..*?_aliases
files for the user
How to handle interactive logic in a non-interactive shell?
We don't, just fetch the aliases
How to handle non-standard .*rc file locations
We don't, just fetching aliases, like you do today, just without the need for an extra other file
How about parsing ~/.bash_aliases and/or ~/zsh_aliases. Those are standard and could easily be parsed with a regex.
This will quickly become a problem, since there's no standard for ~/.bash_aliases
. It's just a vague community practice on how one could name a file that contains aliases, but
Then there's the other thing that people use different shells than bash
and zsh
, which would need to be supported as well. These shells might have a different alias syntax which would then need a different parser.
In general, I don't feel too comfortable to support specific shells or external tooling.
The only proper way to fix this (as I currently see), is to go back and revisit allowing users to setup their own shell commands. That way, users can specify the exact way their commands should be executed, with their favorite shell flavour.
This will probably come with some other problems though. A few of Pueue's functionalities would probably need to be disabled if a custom user shell is detected, such as shellescape
, which only support posix shell syntax.
I added a configurable shell command. Could you check the MR out and see if you can use this?
Turns out, there's apparently no way to pre-load any kind of rc
file for bash or zsh in non-interactive mode.
And aliases are only saved after the current prompt has completed, when sourcing a script.
I did some more research and managed to get this working for bash.
shell_command: [
"bash",
"-c",
"shopt -s expand_aliases && {{ pueue_command_string }}",
]
env_vars:
BASH_ENV: "/path/to/your/alias/file"
I had to add another configuration field env_vars
, which allows users to inject/overwrite arbitrary environment variables into processes.
Though, I wasn't able to get this running for zsh. The following should work in theory, but for some reason, it doesn't:
shell_command: [
"zsh",
"-c",
"source /path/to/your/alias_file && setopt aliases && {{ pueue_command_string }}",
]
Nice! That's promising.
@chevdor Could you go ahead and test the branch? I added a small guide on how to test this over there https://github.com/Nukesor/pueue/pull/458
If you're using some other shells, It would also be awesome if you could try to get it running!
I can test zsh/bash. Having a look now.
So it's been a bit of a fight :)
context for the commands below:
alias q=pueue
alias qd='pueued -d'
.zsh_aliases
file defines some aliases including p=podman
I realized that changing the config in pueue.yml
required to restart the daemon. That totally makes sense but I missed that at first so my changes were not "visible".
zsh won't work unless a magic eval
is issued.
I could get it to work using:
daemon:
[...]
shell_command: [
"zsh",
"-c",
". $HOME/.zsh_aliases; setopt aliases; eval {{ pueue_command_string }}",
]
env_vars:
# BASH_ENV: "irrelevant"
then calling:
q shutdown; qd; q clean; q add -- p --version; sleep 2; q
The custom shell is merged, so I'll close this for now :)
A detailed description of the feature you would like to see added.
Currently, the following will fail:
It fails because in the
pueue
context, user aliases are not loaded, sofoo
is unknown. It would be useful to have an option (set as default ?) that loads user's env such as currently set aliases. Addingshopt -s expand_aliases
may help but I did not test.Explain your usecase of the requested feature
pueue
is very useful for a user to queue up a bunch of tasks. It is quick natural for users to already have created aliases for the individual tasks. For instance, a user may already have an alias to runfreshlam && scan
orbrew update && brew upgrade
.Alternatives
No response
Additional context
No response