3 ms·

Hm. I wonder if the bash patching is actually necessary - a syntax failing command like '|foo' still goes into the history, so you could pick it up from there,

by mst 10y ago

Hm. I wonder if the bash patching is actually necessary - a syntax failing command like '|foo' still goes into the history, so you could pick it up from there, maybe via a prompt command. https://github.com/nvbn/thefuck https://github.com/nvbn/thefuck seems like kinda-sorta prior art for this. (and if I'm wrong and/or the bash patch just makes things lots easier, then I'd love to see it posted somewhere people who know the bash source well can see if they can help turn it into a real feature, because custom error handlers seem as awesome as custom completion handlers)

robertelder 10y ago
I tried very hard to create the feature I was looking for without changing the source, but it just wasn't possible. I went through 3 or 4 prototypes, and eventually decided to just change bash itself (which was a good call in hindsight). I've had to make a few more change since too. The source patch is located at ~/.fop/patched-executables/bash-4.3.30-post-patch-call-python-hook.patch is has been applied after the LFS bash patch. This patch is extremely sloppy and breaks certain things, but it does what I need for now. The way it works for bash commands is before handing a line of input off to be processed, it calls an external python hook which decides whether that line of input should be ignored or not, gives the hook a change to perform it's own custom behaviour (such as print an error message).
- mst 10y ago
  Ah, I was thinking about "let it fail with the normal error message, and then print an explanation" - that way people learn to recognise the real error too for when they take the training wheels off. (I checked, even malformed lines like '|foo' go into the history)
  - robertelder 10y ago
    Yeah, there are a few situations where it's a difficult call between getting them used to the 'real' environment vs holding their hand and telling them "bash: syntax error near unexpected token `|'". If I end up modifying it too much, then they start learning an alternate thing that isn't portable knowledge, but in this case I think it should be OK. I would make sense to possibly have a graduated progression where you expose them more and more to the real horrors of using the command line. I guess I'll see how it evolves. Another couple reasons I patched bash: Being able to detect when users use tab completion and using the up key to check history. Those are 2 massive productivity enhancements, and I wanted to created modules where I can verify that they used these.

by mst 10y ago

robertelder 10y ago

I tried very hard to create the feature I was looking for without changing the source, but it just wasn't possible. I went through 3 or 4 prototypes, and eventually decided to just change bash itself (which was a good call in hindsight). I've had to make a few more change since too. The source patch is located at ~/.fop/patched-executables/bash-4.3.30-post-patch-call-python-hook.patch is has been applied after the LFS bash patch. This patch is extremely sloppy and breaks certain things, but it does what I need for now. The way it works for bash commands is before handing a line of input off to be processed, it calls an external python hook which decides whether that line of input should be ignored or not, gives the hook a change to perform it's own custom behaviour (such as print an error message).

mst 10y ago
Ah, I was thinking about "let it fail with the normal error message, and then print an explanation" - that way people learn to recognise the real error too for when they take the training wheels off. (I checked, even malformed lines like '|foo' go into the history)
- robertelder 10y ago
  Yeah, there are a few situations where it's a difficult call between getting them used to the 'real' environment vs holding their hand and telling them "bash: syntax error near unexpected token `|'". If I end up modifying it too much, then they start learning an alternate thing that isn't portable knowledge, but in this case I think it should be OK. I would make sense to possibly have a graduated progression where you expose them more and more to the real horrors of using the command line. I guess I'll see how it evolves. Another couple reasons I patched bash: Being able to detect when users use tab completion and using the up key to check history. Those are 2 massive productivity enhancements, and I wanted to created modules where I can verify that they used these.