-
-
Notifications
You must be signed in to change notification settings - Fork 300
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
Add a syntax for capturing outputs as a string #1416
Comments
Two questions:
Personally I don't think this operation is often enough to warrant a new operator and |
I tend to agree with @xiaq on this one. I am not a big fan of too much magic syntax. |
The counter argument is that the unquoted behavior in a POSIX shell depends on the value of Also, a POSIX shell only has a byte stream between commands on each side of a pipe operator. Whereas Elvish also has a value channel. The Elvish |
I was originally thinking it would be a stringification of everything, but thinking more on it I'm not sure that's actually what I'd want. Perhaps calling it a single-value capture and doing something like turning multiple values into a list would make more sense?
I'm not sure. While I think in an ideal world it would, I think that would be somewhat unusable given the current standard.
After thinking about this for a bit, I think that my main issue is with the use of I think if the syntax weren't already established I would have made |
Hmmm, I would argue that the absence of |
I think it would be nice to have a
$(cmd)
which stringifies the output of the command automatically, as I find in most cases where I'm using output capture in a traditional way, what I really want is(cmd | slurp)
.I've chosen the syntax as it's currently never valid elvish to write
$(
(and obviously mirroring POSIX subshell syntax), but I have no real preference. Perhaps it would be good to force users to use something else in case they attempt to use$(cmd)
without understanding what the difference betweenelvish
and POSIX shells would be.Any comments would be appreciated.
See #1415 for a proposed implementation.
The text was updated successfully, but these errors were encountered: