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
Malformed history kills fish #7497
Comments
Because I stumbled upon this organically, my attempt reducing the reproduction apparently made things a little bit too complicated. Again... XD It's not limited to recalling history, but just typing the last fish@host $> set var (cat /usr/share/dict/words)
fish@host $> time {$var;$var} (one So it works the other way too. The mentioned delay just allows for hitting enter and writing this parser trap into history, where it can be re-triggered, if the variable gets set. |
Is that the OOM killer kicking in? We've had similar reports and discussed just limiting dynamic substitution output at the prompt. |
Does the syntax highlighter (I assume that's what's exploding here) really need to expand those variables at all? Can't this be done in a symbolic way? As a naive user, I wouldn't mind actually overloading the shell on execution by accident, much less if the shell aborts gracefully and notifies me about hitting OOM. However, just typing something should never ever hit any limit or even use up significant resources IMO. |
It does because the variables are in command position. |
Ah, alright, because of Experimenting, it seems fish isn't caring about anything else but This does not break fish: fish@host $> set var (cat /usr/share/dict/words)
fish@host $> time {$var[1];$var[1]} It appears, evaluating only ever However, apparently fish also crashes when the variable is not in command position (as I understand it): |
$var in command position expands to a command and arguments, e.g.:
we should have some sort of protection against very large expansions. |
Yes, that's clever, hopefully we can do that without adding too much complexity. I'll try. What makes this blow up so fast is the fact that cartesian product expansion happens inside > set 5 (seq 5)
> echo { $5.$5 }
1.1 2.1 3.1 4.1 5.1 1.2 2.2 3.2 4.2 5.2 1.3 2.3 3.3 4.3 5.3 1.4 2.4 3.4 4.4 5.4 1.5 2.5 3.5 4.5 5.5
> Curiously, the same happens when there is a space between the variables like So when typing that command, fish tries to compute autosuggestions for any of the list elements. |
@ridiculousfish Thanks, that's actually a rather obvious concept, I didn't think of. Though, I think the syntax checker should still stop expansion after the first list entry, verifying a command, as there is visually no way to tell the error position apart, anyway, and it's constructed enough, to only fail at execution and still be user friendly, IMO. @krobelus Thank you, for the tip. I figured out the command block syntax myself, in the end (via RTFM). However, I think my experimentation above isn't completely unreasonable, I think, in terms of discovering features for a new user. The syntax parsing of the cartesian product only breaks fish, if written in braces, which is why I think there might be something else broken there (may explain the curious case of Tho, executing the Also, could this be an integer overflow? As 100.000^2 exceeds 2^32. (I would love to help with the code, instead of having opinions here, but C++ and a project fish's size is beyond my scope. Thank you all, for being this involved and active <3) Edit: Sorry, I somehow missed the last paragraph, which makes some of my reasoning seem obsolete, or rather ignorant. Still, my point about the cartesian product stands, It think. |
Fixed by a8080e8, see also #7407 (comment)
This is fixed by 594a6a3, it looks like this:
The source should be easy to read - if it's not we should change that. Finding out how to make a change is usually not that hard, |
Thank you for fixing this. <3 @krobelus, I have no doubt the code is of high quality and readable. However, a project this size to me has the main problem of overcoming the complexity of the code base itself. I think experienced developers tend to forget what that looks like at the beginning. For example, if I wanted to understand how fish's parser works, where would I start? What would it take? To me it looks like Off-topic: I am actually thinking about this from time to time. The opensource ecosystem would be much more approachable, if we had a thorough "How to even start?" documented in detail for some exemplary projects. I imagine a service where users could share notes on repository exploration, or experienced developers could explain their take on a code base of a remarkable project (as a tribute? a love letter?). Maybe a repository snapshot on the left (this doesn't need to be the latest state; future retakes could be pointed out as valuable "crime scene" analysis, too), with a wiki-like article on every file and hierarchy level on the right; references to code sections within the file or the global scope; links to fundamental algorithms, conventions or idioms. I assume here most projects aren't really that dissimilar in the end, but all of them are very different from where you were left off learning the basics. With much conceptual bloat from modularization, testing, building, git and documentation. And this entry barrier is actually even selecting for somewhat unrelated qualities, not inherently linked to the potential quality of contribution. That is, of course, if you don't make a circular argument for the suggested problem at hand. |
Trying to discover multi-line command blocks to use with
time
, I discovered a bug instead:1. Enter malformed command "block", containing a variable not set, or not set to danger yet...
2. Setting the variable as a somewhat long list (e.g.
set words a b c
, won't break fish)3. Recalling the command history until the malformed command appears
fish -d 4
only shows the shell died bySIGKILL
.That's all I got <3
The text was updated successfully, but these errors were encountered: