FOSSwire

Maybe you've just installed a dual boot system. It's all going well and good, but when you start the computer, Windows appears at the bottom of the boot menu.

You might still want to use Windows as your primary operating system, and so pressing down a few times and Enter each boot time could get frustrating. You'd ideally like Windows at the top of the boot menu, and Linux second.

In this quick tutorial, I'm going to show you how to use KGRUBEditor, a program for editing your boot menu settings, to re-order the menu so that Windows is first, and the default choice.

(If you'd rather quickly edit the configuration file by hand, without installing new software, take a look at this alternative tutorial).

First of all, we need to install KGRUBEditor. You'll probably find it in your package manager if you search for kgrubeditor (help on installing packages).

Once it's installed, launch it, from the System category.

You will be asked to give your (or root's) password to continue. A word of warning - through KGRUBEditor, you are editing important settings that tell your computer how to start up properly. Avoid changing settings you don't fully understand!

Once you're in, you'll see something a bit like this (your entries might look slightly different).

Each row in the top pane should correspond to one of the choices you see when the computer starts up.

Click on the Windows row, so that it is selected. Now go to the menu and choose Actions > Move to Top.

Once the Windows entry is at the top, you need to also set it as the 'default' entry, so it is the first choice to be selected (otherwise it will be at the top, but not selected).

Right-click the entry for Windows, and choose Set as default.

And that should be it. You can now close KGRUBEditor and reboot to find Windows your default choice. To boot Linux, you can just press down once to the first Linux entry and press Enter.

I recently posted about using nohup to run a command, particularly on a remote machine, that keeps running even when you close the terminal or connection that started it.

Several people in the comments there also suggested GNU Screen for a similar purpose.

So, what is Screen? It describes itself as:

... a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.

Basically, among other things, it can create multiple 'virtual terminals' that run inside a single physical terminal or connection, and offers you additional features, such as resuming sessions later and basic copy and paste.

What we're interested in in the context of my other post is running commands in the background on remote machines, so I can start a command running, disconnect from SSH, but the command will stay running.

Screen, unlike Nohup, will allow me to come back later and interact directly with the terminal that I started, not just dump the results of a command to a file.

On your remote machine, start the program:

$ screen

You'll get a brief copyright notice and such, just press Space as directed. You are now running Screen (although it won't look any different to a normal terminal session by default).

Now, feel free to go off and start that important task. Once it's up and running, press Ctrl+A, then Ctrl+D. Screen sends you back to your shell and you can now disconnect.

Later, when you want to come back, run:

$ screen -r

Your old session is restored! Anything you started should still be running.

Screen is a lot more powerful than just offering this feature, however, but we'll save the rest for another day.

Finally, when you are actually done with a Screen session for good, quit it by pressing Ctrl+A, then Ctrl+\ or you can simply type exit into the terminal as normal.

[image source]

Oftentimes you'll be in a situation where you want to run a command on a remote machine that will take a long time to complete, but you want to be able to issue the command and then log off and have that command run in the background.

There are many ways you could achieve this, perhaps by using cron or at to schedule the command to run right away. However, there is a better way.

There is a command called nohup built into both the GNU toolset, and most shells, which allows you to run a command in this way. It is so called because the command being run is executed ignoring 'hang up' signals, which are given when you close the terminal you started the program from.

To use this, simply prefix your command with nohup, for example:

nohup wget bigfile

This will still run in the foreground, however, meaning that you will lose the ability to use that terminal while the command is executing. In most cases, you'll want to use the ampersand (&) to run the command in the background.

nohup wget bigfile &

Now you can log off your remote machine, or close your terminal and the command will continue running in the background.

The output and errors from the command you run with nohup are stored in a file called nohup.out in the directory where you started the command, or your home directory if for some reason that's not possible (e.g. permissions).

[image source]