This question has two parts to it. I've typed out a simple script that I'll run (not every time) when I boot into the GUI, but I'm running into a few hiccups. First part is that none of the outputs of these commands show up in terminal, not even cd. So I was wondering what I need to add to the script in order for the outputs of said commands (red) to be displayed in terminal. The other stuff (blue) should probably remain hidden.

Normally, to see the output of a script, you would do one of the following:1. Open a terminal, and run your script from there.2. From Nautilus (the file manager) double-click the script, and choose Run as Script (IIRC). This shows you the output, but the terminal closes once the script finishes. So add a line at the end of your script to pause for user input:

I see on the third line of your script you run gnome-terminal. This will open a new, empty, terminal and the script will just continue to run from where it started. If you want to have the output of the script in the new terminal you launched, you will have to split it up in two scripts (or do one of the above three).

Example files below, replace /home/user with actual path to your homedirectory or where you place the scripts.

It works as intended while in the GUI, opening a new terminal window and outputting the ls command as well as the prompt, waiting for me to press the enter key.

It also works while in a terminal window, as well as during standalone login, albeit it doesn't pop-up a separate terminal window (the if-then-fi statement gets bypassed).

The goal of the snippet of code is to make sure terminal output gets a chance to be seen when a script is run within the confines of the GUI. Naturally, if you run the script in a terminal window in the first place, it is no longer necessary to create another separate terminal window just for the sake of giving output when the main terminal window is already there to give output.

The read command at the end of the script should fix the problem with the terminal window getting closed too quickly. As an alternative, the sleep command can be used in lieu of read. Another suggestion is to change gnome-terminal's preferences and set it to hold the terminal open once the script returns control to the operating system.

At least as far as I remember and have experienced firsthand. Also doesn't the read command require a variable (even if it's a dummy one) at the end?

Vincent Vermeulen wrote:...that also kills my "two scripts" solution

I didn't meant to step on you. I was reading the thread last night and saw your two-script solution. I thought to myself that maintaining a complementary script wasn't necessary when it can get more efficient by doing it inline. Hence the post.

Hope this clarifies things.

o Give a man a fish and he will eat for a day. Teach him how to fish and he will eat for a lifetime!o If an issue has been fixed, please edit your first post and add the word [SOLVED].

Vincent Vermeulen wrote:2. From Nautilus (the file manager) double-click the script, and choose Run as Script (IIRC). This shows you the output, but the terminal closes once the script finishes. So add a line at the end of your script to pause for user input:

I didn't think that it would matter, but in case it does... 32bit mint10 gnome?

I use Mint 9 (LTS) Gnome.

I have no idea what you did there, but I copied and pasted as you said with the same result as all the others.

Humor me for a moment, you copied and pasted everything literally? You do realize the ellipses (...) at the bottom of the code fragment is meant for you to put the actual commands there. I'm not trying to be patronizing, but everyone knows how prone to misinterpretation the English language is.

Save the above script in a file and enable the necessary permissions. Run the script inside a terminal window. You should see some output. Run again the script from Nautilus. It should open a terminal window and you should see the same output. If the read command doesn't work, change the shebang line from #!/bin/sh to #!/bin/bash and try again. If you still don't see any kind of output then I do not know why. Probably it's the difference between Mint 9 and 10, but I can't fathom that is the bottom-line reason.

Now, as far as executed commands not giving you any feedback, that's not uncommon. It is normal and standard convention that if a command does not return any message, then the command ran successfully. It will only provide feedback when necessary, such as if there was an error or it needs to provide output based on what was requested.

If you still want some feedback regardless if a command ran successfully or not, then it is possible. Apart from the set -x command mentioned earlier, there are at least two other ways:

(1) Depending on the command, you can add the -v switch. -v means verbose output, i.e. it will provide feedback as to what is going on. Not all commands support this switch, though. You will have to consult the man pages to find out. E.g.:

(2) Commands also generate what is called an exit code. If the command runs successfully, it exits passing the value 0 (zero) to a special variable $?. Non-zero values usually means -- you've guessed it -- errors or some other issue. As always, read up the man page for the particular command to find what exit code it generates. The following code fragment demonstrates how it's used:

I didn't meant to step on you. I was reading the thread last night and saw your two-script solution. I thought to myself that maintaining a complementary script wasn't necessary when it can get more efficient by doing it inline. Hence the post.

Hope this clarifies things.

Thanks I don't know what I did wrong last night, but when I had a terminal open, and would launch my script through the file manager (double-clicking), it wouldn't open a new terminal and the output wouldn't show either. Copy & pasted your script, and now it all works. Ah well

Pilosopong Tasyo wrote:Humor me for a moment, you copied and pasted everything literally?

HAHAHAHAHAHAHAHAHA, I had a good laugh with that. I might be a n00b, but I'm not a N00B! Yes I removed the ellipses. That and this time I tried changing it to bash, which worked... well enough. I was hoping to have the command prompt available after everything is said and done. Now when I press enter, it closes with no prompt available. BUT I can settle for that. Thank you for your help, I appreciate it.

In a nutshell, the entire code fragment tries to determine if the script is indeed running within a terminal session/window or not (line 1). If it is, proceed with normal execution (the whole if-then-fi statement is bypassed). Otherwise, suspend current script (parent process), open a terminal window and run self a second time (line 5) as a child process. The $0 parameter is shorthand for the complete location and name of the script (self).

On the second pass, line 1 will now say that the script is indeed running in a terminal window, so if-then-fi gets ignored and the remainder of the script gets executed. Once this child process is finished, it returns control to the parent process which was suspended earlier. Since the child process was able to accomplish what the parent process was unable to do on the first pass, there's no point in executing the remainder of the script. Hence line 6.

Oh, dôh... This feature is builtin (at least for direct launching of scripts) the gnome terminal

Open gnome terminal, go to Edit -> Profile Preferences, Title and Command tab, and change "When command exits" to "Hold the terminal open". Now run your script from the file manager by double-clicking it, and choose "Run in Terminal". Now it shows you all the output, and allows you to scroll back, until you close the window.

Following is a further improvement of Pilosopong Tasyo's example. It now also passes command line arguments on restarting the script, optionally pauses before the terminal window closes, uses your system's default terminal so it works on other desktop environments, and just the 4 lines of code need to be inserted at the top of any script.

Double-clicking a script in your file manager and choosing "Run" launches a terminal that automatically pauses at the end. Choosing "Run in Terminal" will run on a normal terminal, that doesn't pause at the end but closes the window. Starting the script from inside a terminal directly doesn't pause at the end either (but you go back to the prompt). I kinda like how this works.

I know it was already marked solved, but had some more Bash skills to hone