I have been trying, using the External Tools plugin, to execute a bash script or interactive bash from within CudaText, but succeeded in neither. Is that not possible at all?
Doing similar things using cmd in Windows was rather easy and straightforward.
Executing a shell (Linux)
Actually, I would like to execute a bash script, or an interactive bash instance, when I am working on a program in C, C++, or another compiled language. Here are three simple scenarios that illustrate why being able to do so is essential.
1) Upon successful compilation, gcc would respond with no message at all, which, when done from within CudaTExt, is hard to distinguish from doing nothing at all, or from a process being stalled. Therefore, I would prefer to run (say) g++ not directly but from a script: if the compiler ends with error code 0, the script would echo a message such as "Compilation successful".
2) A program that needs an input from the keyboard would not execute correctly if run within CudaText in the way suggested in the wiki. Instead, it needs to be executed as a shell command, and thus a shell has to be spawned from the editor. Upon program termination, the script would pause until the user presses a key, and then the shell instance itself terminates: something like
({FileNameNoExt}; read -s -n1 -r -p "Press any key to continue ... "; echo)
3) Sometimes it makes sense to spawn a shell with no specific script to execute but with {FileDir} as the current directory. Thus the user would be able to run their program with redirection, piping, etc., and also to do auxiliary and maintenance work as needed.
These are but three common ways to make use of running a shell and shell scripts from within an editor. And all this I can do easily in the Windows version of CudaText but, alas, not in Linux.
1) Upon successful compilation, gcc would respond with no message at all, which, when done from within CudaTExt, is hard to distinguish from doing nothing at all, or from a process being stalled. Therefore, I would prefer to run (say) g++ not directly but from a script: if the compiler ends with error code 0, the script would echo a message such as "Compilation successful".
2) A program that needs an input from the keyboard would not execute correctly if run within CudaText in the way suggested in the wiki. Instead, it needs to be executed as a shell command, and thus a shell has to be spawned from the editor. Upon program termination, the script would pause until the user presses a key, and then the shell instance itself terminates: something like
({FileNameNoExt}; read -s -n1 -r -p "Press any key to continue ... "; echo)
3) Sometimes it makes sense to spawn a shell with no specific script to execute but with {FileDir} as the current directory. Thus the user would be able to run their program with redirection, piping, etc., and also to do auxiliary and maintenance work as needed.
These are but three common ways to make use of running a shell and shell scripts from within an editor. And all this I can do easily in the Windows version of CudaText but, alas, not in Linux.
@kvichans,
i see the problem - make a tool on Linux, on Ubuntu.
test file ww.sh
tool props:
file.
now run this tool, it prints "dd" to output panel.
all ok.
now change tool prop "capture" to "nothing".
expected: tool opens Bash terminal window.
reality: nothing opens.
i see the problem - make a tool on Linux, on Ubuntu.
test file ww.sh
Code: Select all
#!/bin/bash
echo ddd..
file.
now run this tool, it prints "dd" to output panel.
all ok.
now change tool prop "capture" to "nothing".
expected: tool opens Bash terminal window.
reality: nothing opens.
- Attachments
-
problem is in Bash, it dont stay open after run script.
@topic starter,
see this page how to keep Bash opened after run script.
https://askubuntu.com/questions/20330/h ... e-terminal
@topic starter,
see this page how to keep Bash opened after run script.
https://askubuntu.com/questions/20330/h ... e-terminal
Hi, Alexey and Andrey,
To me, the problem does not seem to be in keeping a started shell alive.
One way to keep the shell (and the program output on screen) present is
to make the shell wait for a user input: I have mentioned how to do that
in my previous post. The real problem, however, is that the shell, or a
shell script, seem to be failing to run at all.
Here is attached an array of tool property boxes to illustrate my point
(as seen, the first row is for Windows, the second for Linux).
The first column shows how I run a compiled C++ program in the Output panel.
All is fine, unless the program has to do some input from stdin. In that
case in fact no input takes place, the program's variables remain uninitialized,
and then of course the program runs nonsense.
This happens both in Windows and in Linux, and is obviously not directly
related to running shell scripts, but it is a problem with the plugin.
Now, being unable to run my program directly in the Output panel, I come
to the second option: running it in a console/terminal. This is seen in
the second column of tool configurations. Here, the Windows's cmd is
executed correctly, but I can achieve nothing similar in Linux with bash
(second row centre in the picture). (If the program got running at all,
it should have done its input while in the terminal, printed results,
and only then disappear. But nothing like that happens.)
The third column shows tools for running a bare console / terminal –
no other programs or scripts get involved. Again, the tool works in
Windows, but shows no signs of life in Linux.
To me, the problem does not seem to be in keeping a started shell alive.
One way to keep the shell (and the program output on screen) present is
to make the shell wait for a user input: I have mentioned how to do that
in my previous post. The real problem, however, is that the shell, or a
shell script, seem to be failing to run at all.
Here is attached an array of tool property boxes to illustrate my point
(as seen, the first row is for Windows, the second for Linux).
The first column shows how I run a compiled C++ program in the Output panel.
All is fine, unless the program has to do some input from stdin. In that
case in fact no input takes place, the program's variables remain uninitialized,
and then of course the program runs nonsense.
This happens both in Windows and in Linux, and is obviously not directly
related to running shell scripts, but it is a problem with the plugin.
Now, being unable to run my program directly in the Output panel, I come
to the second option: running it in a console/terminal. This is seen in
the second column of tool configurations. Here, the Windows's cmd is
executed correctly, but I can achieve nothing similar in Linux with bash
(second row centre in the picture). (If the program got running at all,
it should have done its input while in the terminal, printed results,
and only then disappear. But nothing like that happens.)
The third column shows tools for running a bare console / terminal –
no other programs or scripts get involved. Again, the tool works in
Windows, but shows no signs of life in Linux.
By the way, I would not be against moving this discussion to the Russian-language part of the forum.
I initially posted in English, because I thought that maybe there will be more people interested.
Since that turned out not to be the case, perhaps it would be more natural to discuss in Russian,
which it seems is your mother's language, and to me it is at least a bit less foreign than English is
What do you say?
I initially posted in English, because I thought that maybe there will be more people interested.
Since that turned out not to be the case, perhaps it would be more natural to discuss in Russian,
which it seems is your mother's language, and to me it is at least a bit less foreign than English is
What do you say?
Partially solved at russian forum
https://wiki.freepascal.org/CudaText#To ... n_terminal
https://wiki.freepascal.org/CudaText#To ... n_terminal
https://wiki.freepascal.org/CudaText#To ... n_terminal
https://wiki.freepascal.org/CudaText#To ... n_terminal