Closed drewburlingame closed 2 years ago
the spike/piping-to-options branch contains a working implementation. To merge, it needs a renamed registration method, tests and docs. We also need to verify if this is the right approach.
another design would be to use a directive to specify the option to pipe to. example.com [pipeto:--fidgets]
. Just parking the idea here for thought. I don't like the idea of using directives to populate arguments but I don't have a strong reason not to and it has the perk of not needing a special character sequence to denote the target option.
consider using xargs conventions: $0,$1,$@. Separate on newline or space, poosibly configurable in app, command and/or directive. https://en.wikipedia.org/wiki/Xargs
implemented in v6. went with $*
as default target symbol, and can target any argument. override with AppSettings or [pipeto: ] directive
The current piping features enables piping to a list operand.
It would be useful to pipe into options as well.
Scenario:
account find --active | db-migrate --accounts=$pipe$ /migrations/bug-fix-1.sql
Using the results of theaccount find
command to provide a list of accounts to run the migration for.The feature was simple with a single list operand because it was obvious where the pipe would go.
With multiple list options allowed plus the list operand, we need to be clear which argument is the target.
1st, we need to determine the symbol to use as the identifier. It should be able to be run in a script and not be confused with other variables, environment-variables, etc. If there's a standard, let's use that.
-
(https://unix.stackexchange.com/questions/16357/usage-of-dash-in-place-of-a-filename) although that may conflict if running the command on Linux.2nd, we need the rule for how it's used. I think it only needs to be specified for options and if not specified, then it goes to a list operand. Or... is it just too confusing overall?