You can get a GUI by running:

However, then you will get the whole thing. This means it will also include all those applications and games that Ubuntu Desktop comes with. Don’t want that. You can get a much slimmer version by running:

In both cases, reboot when it’s done and it should boot into the regular desktop environment.

Administrator password

For some reason, you won’t be able to access the Synaptic Package Manager, or add package sources in the Software Center thing (or what it was called) until you have set a root password. When you open these it doesn’t ask you for authorization like other administration stuff does, but for the administrator password. I don’t know why this happens (can’t recall it happening when using regular Ubuntu Desktop), but you can set the root password if you open up a terminal and run:

If someone has an explanation to why this happens in Ubuntu Server and not in Ubuntu Desktop, I would like to hear about it!

rgbstock.com

That’s all there is to it! grep is the command, r makes the search recursive (i.e. in the target folder and all its sub-folders), l means it will list the name of all the files where it finds the text, "some text" is the string to search for, and finally, the dot at the end means to start the search in the current directory. And just to clarify, this searches for text inside of files, in the content of the files; not the filenames.

There, now I know where to find it when I forget it next time. And perhaps I have helped someone else too

Good night!

I know I’m using bash, and I don’t really care about the version. Or that I’m using bash actually… But anyways, to make it more useful you can run this:

You will then get a prompt which contains your username, hostname and current working directory. Much more useful in my opinion. If you have a different opinion, please share

You can find more stuff to put in your prompt by reading the prompting section of the bash man page.

How to find it

First command figures out where the java command is located. We then use ls -l and finds that /usr/bin/java actually points to ../java/bin/java. As an absolute path, that would be /usr/java/bin/java. This means our JAVA_HOME should be set to /usr/java.

(I have assumed that Java actually is installed. If it isn’t, you need to do that first)

But where is whereis?

The above example is how it normally goes for me on for example Ubuntu (although the directory you get might be different). However, this is what happened when I did it on a machine running SunOS 5.10:

Turns out that command doesn’t exist on Solaris. Luckily we can use a command called which instead, which gives you the same result.

But I want to use whereis!

Well, turns out you can! Apparently the command actually does exist. It’s just not in your path by default. This command (and some others) can be found in /usr/ucb, so we just need to add that to our PATH and we can use it like normal.

How to set it

There are various ways of doing this, and in my case the simplest way was to add the lines below to a file called ~/.profile.

The last two lines shows how to add /usr/ucb to your path, which you can skip if you don’t feel a great need to use whereis later.

In my case I got 8 regular findings and 63 lines of “find: cannot read dir /foo: Permission denied”. Quite a lot of noise I really don’t care about. Using my new knowledge about streams it is easy to get rid of all that though. Just pipe stderr into /dev/null.

Voila. Clean output.

Remember that when you do this all errors will be sent to nowhere. So if there was any other errors, they would also be gone. In this case I don’t care, but in other instances you might want to do something else. For example direct it to a log file rather than to oblivion.

The result was not what I expected however. All I got to see was the messages that had been printed out. No exception or stack trace to be seen.

The reason for this is quite simply that a Unix process has three different streams: stdin(0), stdout(1) and stderr(2). When we pipe output from one process into another we sort of connect stdout of the first one to stdin of the second.

So, to be able to see my giant stack trace, we can for example redirect stderr to stdout. This way we will get both streams into stdin of the next process.

Fancy, huh? We can also direct these streams into files, which might come in handy.

If you want the output to be appended to the log files instead of replacing them, you can do adjust the command to this:

Turned out it was quite simple to enable and disable this feature. To enable it, just open up a Terminal and run the following command:

When you reboot the next time, you will see all the fun stuff happening during the boot up. If you get tired of it, you can disable it again by running:

That’s it!