There are many cases where it is desirable to use --exec or --exec-batch` with a shell command, including having access to aliases and shell functions, being able to use pipes and redirection, etc.
Having an option that automatically handles the boilerplate of $SHELL -c for you would make those use cases a lot more convenient.
Before jumping in and implementing this though, there are some open questions I would like answered:
[ ] What shell is used? On unix systems, do we use the value of the SHELL environment variable, always use sh, try to use bash with a fallback to sh, or maybe try to use SHELL but fall back to sh? On Windows, do we use powershell or cmd.exe? And if the former, what do we do if it isn't available? what about cygwin?
[ ] Are unix shells consistent in supporting -c? I don't know of any that don't, but do we need to worry about SHELL being set to something weird that doesn't?
[ ] How should the command be passed in? As a single string argument? As an arbitrary number of arguments that are joined by spaces? I'm leaning towards a single string.
[ ] Should we support --exec-shell-batch or just --exec-shell?
As mentioned in https://github.com/sharkdp/fd/issues/1354#issuecomment-1657208919
There are many cases where it is desirable to use
--exec
or --exec-batch` with a shell command, including having access to aliases and shell functions, being able to use pipes and redirection, etc.Having an option that automatically handles the boilerplate of
$SHELL -c
for you would make those use cases a lot more convenient.Before jumping in and implementing this though, there are some open questions I would like answered:
sh
, try to use bash with a fallback tosh
, or maybe try to use SHELL but fall back tosh
? On Windows, do we use powershell or cmd.exe? And if the former, what do we do if it isn't available? what about cygwin?-c
? I don't know of any that don't, but do we need to worry about SHELL being set to something weird that doesn't?