Cannot get terminal application to launch with a graphical launcher when successful in terminal
I have been having an extremely annoying problem. For the record, I am relatively new at this. I've only been working with unix-based OS's for roughly two years, mostly Xubuntu and some Kali. I am pretty familiar with the BASH language, as that's the default shell for debian. Now, I've made this BASH script that works properly when it is accessed through the virtual console, xfce4-terminal 0.6.3. I've created a symbolic link in /bin to access the script from any directory, as most people do, I think. This is the script itself, designed to connect to WiFi access point from a CLI or virtual terminal.
This application when summoned via the symbolic link I've created for it, "w-cmdr", runs perfectly. But when I create a graphical launcher, the same kind that functions, say, an Internet browser, or a common application such as LibreOffice, it will not function. It executes the first actual command, which introduces the script and awaits the "command" from the script's "command menu" (as shown in the first picture). But anything actually entered into that menu results in a script failure, from which the only way to exit the script is CTRL+C. The failure is shown in the second picture.
What I don't understand is why it runs when originally executed by the CLI or virtual console, but when summoned by a graphical application launcher, which is configured to bring up a virtual console via the "run in terminal" option, as shown in the third picture, fails with no explanation. I use this script often, even when I'm using the GUI, and having a graphical launcher is honestly, not terribly important. But in enhances my laziness, which is the point of shell scripts haha. So please, someone help me. This is very frustrating. Any suggestions or ideas would be appreciated.
Whatever shell is running your script via the "run in terminal" command is a shell that doesn't know about the recent bash and ksh [[ expression ]] test syntax.
If you convert all occurrences of expressions of the form:
to:
or convert the entire if ... elif ... fi tree to a case statement:
then most shells based on Bourne shell syntax should be able to run your script.
However, note that naming a function test (overriding a utility normally found in /bin and the built-in found in most shells that accept Bourne shell syntax) is a VERY BAD idea.
Unless all of the utilities invoked by your script are found in /bin, you also need to set PATH to include a list of the directories containing those utilities.
This User Gave Thanks to Don Cragun For This Post:
Thank you very much for your time and knowledge, the syntax error of the test statements were the problem. I'm just curious, what is the difference between:
and
I was taught to do the first when I first started to write scripting, and it's never given me any problems until this, which has now been fixed.
---------- Post updated at 03:43 AM ---------- Previous update was at 02:49 AM ----------
Also, using the "case" statement in this really made it way better. And I had never figured out how to properly use it until I saw what you wrote, so again, thank you. Showing me all of this has really improved my script and has given me more knowledge to equip me to write better scripts.
Last edited by Huitzilopochtli; 02-15-2016 at 01:40 PM..
Thank you very much for your time and knowledge, the syntax error of the test statements were the problem. I'm just curious, what is the difference between:
and
I was taught to do the first when I first started to write scripting, and it's never given me any problems until this, which has now been fixed.
---------- Post updated at 03:43 AM ---------- Previous update was at 02:49 AM ----------
Also, using the "case" statement in this really made it way better. And I had never figured out how to properly use it until I saw what you wrote, so again, thank you. Showing me all of this has really improved my script and has given me more knowledge to equip me to write better scripts.
I hadn't noticed that the first line of your script contains a leading <space> character before the #!/bin/bash, so RudiC is probably correct in saying that that is why your script wasn't run using bash as its interpreter. Unless #!interpreter_path starts in column 1 on the 1st line in your file, that line is just a comment and has absolutely no effect on what interpreter will be used to run your script.
You haven't told us what operating system you're using, but it looks like the default shell on your is a Bourne shell or something like dash that doesn't include a lot of the bells and whistles provided by shells like bash and ksh that are extensions above and beyond what is required by the POSIX standards.
In POSIX-conforming shells the command:
is a synonym for the command:
and there is no specification of what:
does. The test and [ commands are utilities and they are often built-in into the shell as well as being available as stand-alone utilities. The [[ expression ]] is not a utility; it is a part of the syntax of those shells that provide this extension.
So, using [ "$var" = "string" ] is portable to a wide range of shells. And on shells that support [[ "$var" == "string" ]], it is often a little bit faster, often supports more operators than test, and has different requirements for when double-quotes are required and how shell variables are expanded.
I'm glad my sample case statement helped you figure out how it works. We're here to help you learn how to use the tools that are available to you on UNIX, Linux, and similar systems.
There is a space before the shebang on the first line. The OS I'm using is Kali (the new Rolling version) which I believe by default uses Bourne again shell as the interpreter. Also, the way that I wrote the shebang with the space leading has always been how I've always written it. I didn't know that it made a difference for there to be a space?? But I'm new at this, also. And thank you for clarifying about the test statements, that was very helpful. So should the shebang not have a space in front of it?? If I were to use this script on a different OS that doesn't use bash, and that space were there before the shebang, would that different OS not know what interpreter to use?? Again, thank you for your time.
---------- Post updated at 04:48 PM ---------- Previous update was at 04:44 PM ----------
@ RudiC
I've been trying to implement the "select" statement in my script but it hasn't been very successful, as it is a very unfamiliar concept to me. But thank you for your time and idea, I'm sure if I fiddle around with it long enough, I'll get the hang of it haha.
There is a space before the shebang on the first line. The OS I'm using is Kali (the new Rolling version) which I believe by default uses Bourne again shell as the interpreter. Also, the way that I wrote the shebang with the space leading has always been how I've always written it. I didn't know that it made a difference for there to be a space?? But I'm new at this, also. And thank you for clarifying about the test statements, that was very helpful. So should the shebang not have a space in front of it?? If I were to use this script on a different OS that doesn't use bash, and that space were there before the shebang, would that different OS not know what interpreter to use?? Again, thank you for your time.
I repeat: " Unless #!interpreter_path starts in column 1 on the 1st line in your file, that line is just a comment and has absolutely no effect on what interpreter will be used to run your script." A leading space makes a HUGE difference. Any attempt on any UNIX-like operating system to exec a shell script that does not have #! as the 1st two characters in that file will be run by that system's default shell.
If the #!/interpreter/path start in the 1st character of the 1st line of your file and the operating system doesn't find an executable file with that path, you're likely to get a cryptic message like:
(assuming that your login shell is bash and the name of the shell script you were trying to execute was named script_file).
With the space there, another operating system (or your own) will know exactly what shell to use to invoke your script (that system's default) which will probably be named sh and might or might not be linked to bash, ksh, dash, ..., or a 1970's vintage pure Bourne shell depending on what operating system you are using at the time.
Of course, you can always use:
to have bash run script_file no matter what the first line of script_file looks like.
This User Gave Thanks to Don Cragun For This Post:
Hello All,
I have a text file containing output from a command that contains lots of escape/control characters that when viewed using vi or view, looks like jibberish. But when viewed using the cat command the output is formatted properly.
Is there any way to take the output from the cat... (7 Replies)
So, I'm in a graphical terminal (xfce4-terminal) and I was wondering, would there be a way to type a command, and it run in a new terminal window?? An example would be like, say that I want to open a .txt file, but I want it in a different window, instead of the one that I'm currently using because... (1 Reply)
After installing centos iam not able to see the terminal icon in the applications menu to launch the command prompt in Centos.
However iam able to see the Open Terminal menu, when i right click and it is not working.
let me know what are the things i need to check.:b: (1 Reply)
After I installed OS X Lion I haven't been able to launch x11 remotely (using ssh) from Terminal.
It works fine locally, and also remotely directly from the Xterm.
I log in to the unix server at my university from the terminal like this:
ssh -l -X login@host.com
This used to launch... (1 Reply)
Hello,
I have a PERL-TK based GUI from which I want to launch a command on an existing UNIX terminal (this is also the parent terminal for this perl based gui window). The command I want to launch is interactive (there is no intention to interact with that command from the same PERL gui i.e. no... (2 Replies)
i wanted to execute some terminal commands on local linux, parse their output and display it to the user, i checked netcat source code but i couldnt understance it since im new to c (and linux at the same time).
so i was wondering if there is away to run an instance of terminal hidden, read and... (15 Replies)
I developed a script in Lingon (which is an automated script editor developed for OS X) that is used to automatically restart programs only if they crash. The script itself does just that, but I only want it to load if I'm going to use the specific application that it's designed to protect. In the... (2 Replies)
I developed a script in Lingon (which is an automated script editor developed for OS X) that is used to automatically restart programs only if they crash. The script itself does just that, but I only want it to load if I'm going to use the specific application that it's designed to protect. In... (3 Replies)
Hi,
I am a newbie here. Trying to find a way of writing a script to launch multiple terminal or console windows on solaris 9. I used to be able to do this using cmdtool on older versions of solaris and it was even possible to configure the size and screen position of the window and the title. ... (5 Replies)