-
-
Notifications
You must be signed in to change notification settings - Fork 156
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
pitfall - IFS= read x doesn't set x (read --raw-line or for <> loop instead) #2012
Comments
Hmmm I just reproduced this ... Let me look into this, thanks for the clear report! |
Hm funny that it works in But I think there's still a bug here. I think it is probably related to lack of dynamic scope in procs Our replacement for dynamic scope is I'll look into it a little more ... hm |
Interesting! Thanks for looking in to this. I didn't know about
I just recently started learning YSH, and it's been great so far. Love the project! |
OK wow, now I see the problem... It's because
Actually I was confused about this for a long time ... I thought that
So basically YSH creates the So bottom line: I will add
And then let me think about what we can do about this It will also affect Hm hm |
This is #2012 I'm not sure if can prevent this, but we want a better idiom. Something like: read --line-raw read --line-unbuffered read --line-unbuf read --line-u
And --with-eol This addresses the dynamic scope IFS issue in #2012. Documented as the recommended idiom. TODO: we also want buffered reading of lines: for line in <> { echo $line } for i, line in <> { echo "$i $line" }
I implemented
So you don't have to use the old shell idioms Documented here I guess I will turn this bug into "do something about IFS= read -r` in YSH ... that is confusing Maybe we need a lint rule or something |
I am running release build 0.22.0 of oils-for-unix on Arch Linux.
If I run this code with ysh, I only get blank lines printed to the screen. It should pass the lines that the while loop prints to stdout.
If instead I make the proc a bash style function I get the expected output.
Am I reading from stdin correctly in the proc or is this a bug?
The text was updated successfully, but these errors were encountered: