Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I recently installed 12.04.
When I try to edit a file with gedit, I can't use the terminal until I close the editing file or I have to open a new terminal. But I think I didn't have this problem with 11.04, however I'm not sure.
Is there anyway to avoid this and to use same terminal while editing files.

share|improve this question

marked as duplicate by Seth, don.joey, Andrea Corbellini, Jorge Castro, Avinash Raj Jan 4 '14 at 3:30

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

up vote 63 down vote accepted

Short Answer

In the unresponsive terminal:

  1. Hit Ctrl+Z.
  2. Type bg and enter.
  3. Type disown and enter.

Long Answer

In the unresponsive terminal, hit Ctrl+Z, this will "pause" the process (or "job") and return the console control to you. However, you'll notice that gedit becomes unresponsive and you can't use it.

Extra: if you want to, you can execute the command jobs, you'll notice that it'll read Stopped for the gedit command, that's why you can't use it.

To make the job successfully run in the background (i.e. to make gedit responsive again), execute the command bg (meaning background). You'll now be able to use gedit, and at the same time have the prompt to yourself.

Extra: now, if you execute jobs, you'll notice that it'll read Running.

You can overcome all of this from the very beginning. When you're launching gedit from the terminal, add an & to the end of the command, so something like this gedit /path/to/file &. This will launch gedit in the background from the first place (you might need to hit Enter a couple of times to get the console control back).

Extra: if you were following these extra notes, you might have noticed that the second time you did jobs, you could see that bash added a & to the end of the gedit command.

Once you get used to this system, you might notice that if you close the terminal, gedit will also terminate, without even a confirmation dialog. To prevent this from happening, run disown, which will detach the gedit process from the terminal, removing it from the list returned by jobs.

share|improve this answer
It's always surprised me that there is no way to immediately background a process that's running in the foreground. You have to pause it first, which sometimes isn't viable. – detly Jul 15 '13 at 13:19
@detly read the part "You can overcome..." again! – guntbert Jul 15 '13 at 13:40
@guntbert - Doesn't help if the process is already running... – detly Jul 15 '13 at 23:22

Just type:

gedit <filename-to-edit> &

This will immediately return the command prompt to you.

share|improve this answer
This is an important unix idiom, and worth knowing. Any command can be run in the background this way. Tools that are interactive obviously will be confused by this treatment, but for example bubblesort war_and_peace.txt % will allow your sorter to crank away at the masterpiece (for a long, long time) while you get on with your work (say, implementing quicksort or something) – Jon Kiparsky Jul 16 '13 at 19:16
@JonKiparsky Amusing example - does make the point. – Joe Jul 17 '13 at 18:29

From man gedit:

-b, --background
         Run gedit in the background.

So, if you run gedit with -b option, it will start in background:

gedit -b [FILE-NAME]

Moreover, next you can create an alias for gedit -b (see here how to create a permanent alias):

alias gedit='gedit -b'

From now, in the future you can use gedit [FILE-NAME] as normal and it will start in background.

share|improve this answer
It's a bad idea to use alias to redefine common commands. You'll find lots of threads about it on stackexchange. It is fine to use an alias with a different name. In a nutshell, aliasing existing commands creates unexpected behavior on your machine if someone else ever uses it (like when trying to help you fix some other problem) and it does the same thing to you when you use another system without those aliases and your commands don't work as you expect. One of the poster children for this is alias rm='rm -i'. It gets you used to deleting things with a second chance that's not always there. – Joe Jul 17 '13 at 18:38

Just type:

gedit FILENAME & disown

Ending a command with & in bash runs that command in the background. However, that process is still attached to the terminal.

Without disown, if you close the terminal, gedit will close, without even prompting you to save an edited file. disown detaches the background process from the current terminal, so that if you close the terminal, gedit will continue to run as normal. Turns out I was wrong, this is not the case for bash, but it is the case for zsh. You still need to run detach after doing ctrl-z and bg, though, even in bash.

You can find out more about the built-ins jobs, disown and the & metacharacter in the manpage for the bash command Manpage icon, especially the section labelled "job control".

share|improve this answer
with disown I was able to keep the gedit open after terminal closed. I didn't get what you said about " this is not the case for bash, but it is the case for zsh" – KrIsHnA Jun 3 '15 at 6:21

This is probably because you opened gedit via terminal. When you do this, you see the command line output that is normally hidden if started via the GUI. The best way to fix this is to open a new terminal window. The other will become available after gedit closes. You can also use the switch the above user suggested.

share|improve this answer
A new terminal window just clutters the desktop, even if it's minimized. Using & with or without disown is much simpler and cleaner. – Joe Jul 17 '13 at 18:42

after typing your command end with "&" sign ie. sudo gedit asaph.php it will prompt for a password then press {ctrl + c} type again sudo gedit asaph.php & done now u will be able to usedat terminal again

share|improve this answer
This works terribly when combined with sudo. That's part of why gksudo and kdesudo were implemented. I just ran your example and it worked, but what it did was leave sudo waiting in the background for a password. gedit was not even started. I had to do an fg to bring it up. Then, I could enter the password and run gedit. Maybe you're relying on the sudo password timeout to skip the password the second time you run it, but that's often set to 0 by default and shouldn't be relied upon. You're essentially doing something twice to do it once. That clutters your history and opens you to errors. – Joe Jul 17 '13 at 18:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.