textadept
textadept copied to clipboard
Order of single commands outputs in a shell script is screwed in the output buffer
Here the shell script edited in Textadept:
output() { echo stdout; echo stderr >&2; }
echo ' --1-- '
output 3>&2 1>&2 2>&3
echo ' --2-- '
The output in the Output Buffer is:
--1--
--2--
stdout
stderr
There are two approaches which solve this issue I can use in the script itself: the first one adds a sleep 0.01
line before echo '--2--'
, the other one adds exec 2>&1
. The script runs in the Terminal environment without the problem with wrong order of outputs. By the way: the same shell script code run with F5 from SciTE prints the outputs in the right order.
Textadept's process spawning is asynchronous, and when a process sends output to both stdout and stderr in a very short period of time, it becomes a matter of which gets polled first, and what output is available at that time. Adding sleep
helps with the flow because it gives the process poller time to process the correct output in the correct sequence.
I don't think there's anything I can do here. If you really depend on sequential output for stdout and stderr, either run your command in the terminal, use sleep
, or perhaps output with timestamps and then sort that output.
Why not using the approach used in SciTE output buffer? Is there any advantage of doing it the Textadept way?
I don't know how SciTE does it. Do you? For the GUI version I rely on Qt's or Gtk's process spawning features, and for the terminal version I have to poll manually. This is the easiest for me maintenance-wise.
Sorry, no idea about SciTE ... I am currently looking into geany ... with a Lua plugin an interesting alternative to going back to SciTE.
Running the script below instead of sh "%f"
at Textadept F5 command line:
#!/bin/sh
exec 2>&1 # make FD 2 (stderr) point to what's currently on FD 1 (stdout)
exec "$PWD/$@" # replace ourselves with the script named by our arguments
resolves the issue. The Output Buffer does anyway not distinguish between stdout and stderr. See stackoverflow question for more details.
That's a reasonable workaround for those that need stdout and stderr to be in sync. Thanks for sharing.