-
Notifications
You must be signed in to change notification settings - Fork 855
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exec-env/exec-file: support "--" to separate command to run #1469
Comments
Hmm, this is not so trivial to implement. Simply passing on the array of strings from the command line arguments on as a new command is simple, but that doesn't allow you to access further shell features (like |
@felixfontein Thanx for the feedback and I agree, that behavior needs to be well-defined to clarify expectations on the user side. Picking up your example: sops exec-env test.env -- foo "bar baz" "b'a'm" ...should internally be creating a command with the following parts:
To sops itself, the argument should present itself as follows:
So its barely a pass-through of arguments with the exception of the first argument after If I had a shell script where I needed to produce an actual command line, I'd have something like this: my_url="${api_baseuri}/${resource_path}"
curl_opts=(-s --fail-with-body --user '${API_USER}:${API_PASSWORD}')
# ...add other options depending on script behavior...
sops exec-env test.env -- curl "${curl_opts[@]}" "${my_url}" Here, the At least that's my take on this issue. |
@ancoron @felixfontein Why not just make sops execute the given arguments, and use an actual shell if we need to expand variables, like edit: Nevermind, it seems |
@uasi The main point of this issue is to support In the description I've presented briefly what the main issue with SOPS is when it comes to dynamic command building as part of scripting. In your example I'd still need to:
The major issue is with variable expansion and control of WHERE it gets expanded without losing readability of the SOPS invocation code. |
My quick hack to work around not being able to pass multiple arguments to _sops_exec() {
local FILE=$1 COMMAND=$2 ARGS
shift 2
ARGS=$(printf " %q" "$@") # %q quotes the arguments properly
sops exec-env "${FILE}" "${COMMAND}${ARGS}"
}
alias sops-exec=_sops_exec which can be used like: $ sops-exec ~/secrets.env foo --bar --baz x y z |
An issue I am facing regularly is that I need to create an actual command that is being executed with
exec-env
orexec-file
with variables. Due to the need to put the whole command line into a single argument it becomes very and error-prone due to quoting issues.A simple example:
If sops could introduce special support for the
--
(double-dash) argument, we could say that everything after it becomes a part of the command to execute and it could look like this instead:For manual/interactive command building, this would also allow to auto-complete file names in the shell we're working in.
Of course, the user would still need to ensure that variable expansion doesn't happen in the shell (using single quotes instead of double-quotes), but that has less error potential than quoting (at least for me).
The text was updated successfully, but these errors were encountered: