sigal
sigal copied to clipboard
Sigal alters the shell removing shell echo if ctrl-c to cancel a build
After doing a ctrl-c to cancel a build, my shell no longer shows text I type, something was altered and hasn't been put back how it was.
Hmm, not sure how this can be prevented ... What is altered ? Colors ?
In bash you can take note of a bunch of detail (like what dir you are in with pwd) and then set the user back to how they started at the end of the script or if the script is interrupted half-way through...
I'll take a look and see if there's an easy solution to it and I might also see if I can upload an ascii animation to show what I'm seeing.
Also, I'm using OSX so might be a point of difference...
The current working directory should not be altered. Any details on what is altered and how to reproduce would be useful.
Hi Simon, my example was bad as it suggested that this issue has something to do with current dir which it doesn't. I was only pointing out that details about the current environment can be captured/stored and ensured they are set the same when the script exits for any reason.
In this case, it's purely the echo being removed from the shell prompt, and I'll try to replicate it tonight if I can and let you know.
@geekpete - Do you have more details on this and what can be done ?
I haven't made the time to test it again but I hope to this week.
Keen on getting some static gallery goodness happening for my largish (130gb) photo collection.
So will try to test it again as soon as I can.
Thanks for following up.
Ok, thanks !
Sorry, still need to test this, will aim to do so.
i have found some issue like this in my tests. it was when i interrupted (control-c) the build during a video rendering.
[1001]anarcat@angela:sigal$ sigal build albums/
Sorting albums [####################################] 100%
Sorting media [####################################] 100%
Collecting files [####################################] 100%
Processing files [######------------------------------] 1/6 0d 00:13:24
Interrupted
[1002]anarcat@angela:sigal1$ [1002]anarcat@angela:sigal1$ [1002]anarcat@angela:sigal1$
the last line here is me typing enter three times. normally, a newline is echo'd on the terminal, which makes each prompt show up on it's own line, but in the above case, nothing shows up at all when i type.
the workaround is to type stty sane and enter (which won't show up in the terminal, but will still work).
it's unclear to me what happens here - presumably something is messing with the terminal's file descriptors somewhere? maybe in the way ffmpeg is called?
I doubt about the ffmpeg call since it is done in a subprocess ; and sigal does not do crazy things with the shell since progress bars and color prints are delegated to click, so I have no idea here (even the "Interrupted" line is printed correctly though it's one of the latest step in this case).
so maybe some weird click / subprocess interaction?
the fact that Interrupted shows up there is irrelevant: things processes write to the terminal show up normally, it's the user input that is not echo'd back.
so maybe some weird click / subprocess interaction?
Could be, I did not manage to reproduce directly with click, it needs more investigation.
Hello,
Here (Raspberry Pi 3 Model B, Raspbian 9, sigal 1.4.0) : sigal build -fd -n 1 --> Good sigal build -f --> Bug = Typing on the command line, nothing appears in the prompt sigal build -f -n 1 --> Good sigal build -f -n 2 --> Bug sigal build -fd -n 2 --> Bug
Nothing interesting in debug.
@Cascador - thanks, so it seems related to the use of multiprocessing, but it happens also without the progress bars and without interrupting the process ?
Alrighty so multiprocessing where the original shell isn't being set back to how it started due to the nondeterministic nature of ordering of processing?
This issues bothers me every now and then (mostly while dealing with errors in self-written plugins). For those also suffering: You get your echo back by running stty echo in the affected terminal.
It could be useful to test after removing the progress bars to see if the problem comes from click ?
FWIW I experience this problem quite reliably whenever sigal emits any error or warning (including contains sub-albums) during processing. My local disk is an nfs mount over a relatively slow LAN (~3ms) so maybe that's helping with reproducability?
@miiichael - Does it also happen in debug mode ?
Well I'll be dipped...I can no longer reproduce (for now...). I'll be back if that changes. :sweat_smile: