Mi blog lah! Το ιστολόγιό μου

22Jun/095

The bashrc bash configuration files

The default shell in most Linux distributions is the bash shell. Contrary to all the usability work that has been done to the GUI, the shell is most neglected area.

Current bashrc shell (shows prompt only)

Depicting a shell is not an easy task; in the screenshot above we only show the default prompt. It has the following disadvantages,

  1. It does not differentiate visually between the username and hostname.
  2. It shows the relative path only, making it difficult to realize quickly the full path for the current working directory.
  3. Cannot copy the path using the mouse by double-clicking on it. The ~ is not included in the highlighted text, that one needs to paste and add the remaining part of the path (such as /home/user/)
  4. The point of input changes position on the command line, depending on the size of the path. As you cd into directories, the point of input moves further to the right.

The bashrc project shell

This is the prompt with the bashrc project configuration files. It solves the problems described with the default configuration files found in Linux distributions.

Obviously, there are more to the shell’s configuration files than a usable prompt. For example,

  • the ability to show the partial matches when you press Tab for the first time
  • enabling the shopt options to reasonable values
  • have reasonable aliases for . .. … / -
  • adding –verbose, –interactive to basic utilities such as cp, mv, rm
  • show the exit value of an application if it is other than 0 ($?)

There is a EnhancedBash project for the Ubuntu Linux distribution which might be able to break apart and provide better default configuration files.

If you want to help and add more to the proposed configuration, visit http://github.com/simos/bashrc/

To use the bashrc shell, you need to

  1. Download the latest package from http://github.com/simos/bashrc/ (note the Download button).
  2. Extract the package, open a terminal window and enter the newly created directory.
  3. Run make install
  4. Open a new shell window. The new settings should be activated.
3Mar/084

Designing a command-line translation tool for GNOME

One messy task with GNOME translations is the whole workflow of getting the PO files, translating/updating/fixing them, and then uploading them back. One would need to use command line, and several different commands to accomplish this.

KDE and KBabel has a nice feature that allows you to easily grab all translation files, work on them, then commit through SVN. All through the GUI! It helps a bit here that the translation files for a specific language are located under a single directory.

The current workflow in GNOME translations typically consists of

  1. Getting the PO file from the L10n server (for example, GNOME 2.22 Greek) (also possible to use intltool-update within po/)
  2. Translate using KBabel, POEdit, GTranslator, vim, emacs, etc.
  3. svn co the package making sure you have the correct branch. One may limit to the po/ directory.
  4. Put the updated file in po/
  5. Update the ChangeLog (either with emacs, or with that Perl script)
  6. Commit the translation.
  7. (If you committed on a branch, also commit on HEAD)

Tools such as Transifex (used currently in Fedora) take away altogether the use of command line tools, and one works here through a web-based interface. Apparently, Transifex is having a command-line tool in the TODO list.
What I would like to see in GNOME translations, is a tool that one can use to

  1. Grab all or a section of the PO files from GNOME 2.22. Put them in a local folder.
  2. Use the tools of my preference (translation tools, scripts, etc) to update those translations I need to update.
  3. Commit those translation files that changed (using my SVN account), automatically add ChangeLog entries, also commit to HEAD if required.

I would prefer to have a command-line tool for this, for now, though it would be great if GUI tools would get the same functionality at some point. For a command line tool, the workflow would look like

The workflow would be something like

$ ssh-add
Enter passphrase for /home/simos/.ssh/id_rsa:
Identity added: /home/simos/.ssh/id_dsa (/home/simos/.ssh/id_dsa)
$ tsfx --project=gnome-2.22 --language=el --collection=gnome-desktop --user=simos --action=checkout
Reading from http://svn.gnome.org/svn/damned-lies/trunk/releases.xml.in... done.
Getting alacarte (HEAD)... done.
Getting bug-buddy (branch: xyz)... done.
...
Completed in 4:11s.
$ _

Now we translate any of the files we downloaded, and we push back upstream (of course, only those files that were changed).

$ tsfx --action=commit
Found local repository, Project: gnome-2.22, Language: el, Collection: gnome-desktop, User: simos
 Reading local files...
Found 6 changed files.
Uploading alacarte (HEAD)... done.
Uploading bug-buddy (branch:xyz, HEAD)... done.
...
Completed uploading translation files to gnome-2.22, language el.
$ _
11Nov/070

Localisation issues in home directory folders (xdg-user-dirs)

In new distributions such as Ubuntu 7.10 there is now support for folder names of personal data in your local language. What this means is that ~/Desktop can now be called ~/Επιφάνεια εργασίας. You also get a few more default folders, including ~/Music, ~/Documents, ~/Pictures and so on.

This functionality of localised home folders has become available thanks to a new FreeDesktop standard, XDG-USER-DIRS. xdg-user-dirs can be localised, and the current localisations are available at xdg-user-dirs/po.

A potential issue arises when a user logs in with different locales; how does the system switch between the localised versions of the folder names? For GNOME there is a migration tool; as soon as you login into your account with a different locale, the system will prompt whether you wish to switch the names from one language to another. This is available through the xdg-user-dirs-gtk application.

Another issue is with users who use the command line quite often; switching between two languages (for those languages that use a script other than latin) tends to become cumbersome, especially if you have not setup your shell for intelligent completion. In addition, when you connect remotely using SSH, you may not be able to type in the local language at the initial computer which would make work very annoying.

Furthermore, there have been reports with KDE applications not working; if someone can bug report it and post the link it would be great. The impression I got was that some installations of KDE did not read off the filesystem in UTF-8 but in a legacy 8-bit encoding. This requires further investigation.

Moreover, OpenOffice.org requires some integration work to follow the xdg-user-dirs standard; apparently it has its own option as to which folder it will save into any newly created files. I believe this will be resolved in the near future.

Now, if we just installed Ubuntu 7.10 or Fedora 8, and we got, by default, localised subfolders in our home directory (which we may not prefer), what can we do to revert to non-localised folders?

The lazy way is to logout, choose an English locale as the default locale for the system and log in. You will be presented with the xdg-user-dirs-gtk migration tool (shown above) that will give you the option to switch to English folder names for those personal folders.

Clarification: It is implied for this workaround (logout and login thing), you then log out again, set the language to the localised one (i.e. Greek) and log in. This time, when the system asks to rename the personal folders, you simply answer no, and you end up with a localised desktop but personal folders in English. Mission really accomplished.

If you are of the tinkering type, the files to change manually are

$ cat ~/.config/user-dirs.locale

el_GR

$

and

$ cat ~/.config/user-dirs.dirs

# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you’re
# interested in. All local changes will be retained on the next run
# Format is XDG_xxx_DIR=”$HOME/yyy”, where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR=”/yyy”, where /yyy is an
# absolute path. No other format is supported.
#
XDG_DESKTOP_DIR=”$HOME/Επιφάνεια εργασίας”
XDG_DOWNLOAD_DIR=”$HOME/Επιφάνεια εργασίας”
XDG_TEMPLATES_DIR=”$HOME/Πρότυπα”
XDG_PUBLICSHARE_DIR=”$HOME/δημόσιο”
XDG_DOCUMENTS_DIR=”$HOME/Έγγραφα”
XDG_MUSIC_DIR=”$HOME/Μουσική”
XDG_PICTURES_DIR=”$HOME/Εικόνες”
XDG_VIDEOS_DIR=”$HOME/Βίντεο”

Personally I believe that having localised names appear under the home folder is good for the majority of users, as they will be able to match what is shown in Locations with the actual names on the filesystem.

There will be cases that software has to be updated and bugs fixed (such as in backup tools). As we proceed with more advanced internationalisation/localisation support in Linux, it is desirable to follow forward, and fix problematic software.

However, if enough popular support arises with clear arguments (am referring to Greek-speaking users and a current discussion) for default folder names in the English languages, we could follow the popular demand.

Also see the relevant blog post New Dirs in Gutsy: Documents, Music, Pictures, Blah, Blah by Moving to Freedom.

3May/070

Ubuntu 7.04 DVD edition 4.3GB: done

Have been trying to download Ubuntu 7.04 DVD edition for the last few days. I use the amazing wget program with the command line looking like

wget -c http://www.mirrorservice.org/sites/cdimage.ubuntu.com/cdimage/releases/7.04/release/ubuntu-7.04-dvd-i386.iso

I started off the download in Windows, and over the course of the days I would interrupt and restart the download depending on what I was doing (the -c parameter lets you do that). To make it easier, I wrote a batch file with the command. I named the batch file CMD.BAT and I placed it in my home folder. All nice and well.

While the download was running, I wanted to open a new command prompt window, so I clicked on Start/Run…
Instead of getting a blank command prompt window, I get another instance of a wget download, for the same file. What does that mean? Well, YOU CAN BYPASS Start/Run… BY SIMPLY ADDING CMD.BAT IN YOUR HOME FOLFER.

Sadly, wget does not do any file locking, so I was expecting the worse. I let the download continue anyway and then I would check the checksum.

Download finishes, the checksum is wrong :( .

What to do now?

I kept a note on the file size when both wget commands where running on the same file. So, I should simply cut off the bad part and continue the download from there. Booted in Linux and I did a

split -b 3750000000 ubuntu-7.04-dvd-i386.iso

Two file were created, xaa and xab. I throw away xab and I rename xaa into ubuntu-7.04-dvd-i386.iso.
Now, ubuntu-7.04-dvd-i386.iso contains the correct content but is not the full size. So, I continue with

wget -c http://www.mirrorservice.org/sites/cdimage.ubuntu.com/cdimage/releases/7.04/release/ubuntu-7.04-dvd-i386.iso

Once completed,

$ md5sum ubuntu-7.04-dvd-i386.iso
ca609edf086eea0c821ba34a5c0a709d ubuntu-7.04-dvd-i386.iso
$

which is the same checksum reported at
http://www.mirrorservice.org/sites/cdimage.ubuntu.com/cdimage/releases/7.04/release/MD5SUMS

Success!

2Apr/072

Using SVN for GNOME Translators

Update 3rd June 2009: This is a very old post when GNOME was using SVN for the VCS (now we use git). My blog theme does not show the year, so I am writing this in case you are confused by the post.

Now GNOME uses SVN to manage the development of the software.
To use SVN, the basic relevant commands are described at Getting the most out of Subversion in GNOME.

If you are a translator, the work is further simplified. You would normally new SVN to get a copy of the source code of a package so that you can extract the translation messages of the UI or the documentation. In addition, in some cases you can provide localised images and screenshots.

First of all, if you do not have an account on SVN yet, you need to connect using Anonymous access. You still have all access, however if you want to upload any translations would need to give them to someone else who has such an SVN account.

Furthermore, the source code of a package is often branched during a GNOME release so that when there is ongoing development, the released version of the package is not affected. Branches usually have a name similar to gnome-2-18. The not-branched branch is called trunk (or HEAD, in CVS lingo), where all cutting-edge development usually happens.

To checkout (here checkout means to obtain a copy) the source code of a package.

Checkout trunk as anonymous

svn checkout http://svn.gnome.org/svn/gnome-utils/trunk my-trunk-gnome-utils

Checkout trunk as simos

svn checkout svn+ssh://simos@svn.gnome.org/svn/gnome-utils/trunk my-trunk-gnome-utils

Checkout branch called “gnome-2-18″ as anonymous

svn checkout http://svn.gnome.org/svn/gnome-utils/branches/gnome-2-18/ gnome-utils-stable

Checkout branch called “gnome-2-18″ as simos

svn checkout svn+ssh://simos@svn.gnome.org/svn/gnome-utils/branches/gnome-2-18 gnome-utils-stable

To commit you changes means that you send your changes upstream to the project.
In order to commit, you enter the directory you checked out and you run

svn commit -m “Updated Greek translation”

The changes you make typically include updated your language’s LL.po file, and also updating the ChangeLog file.

You cannot commit in a anonymous checkout. The system knows that it’s you when you are commiting because the checkout command saved the username you used earlier.

In the SVN commands, you can abbreviate checkout with co, and commit with ci. Sometimes this leads to the most common newbie error; you tend to think that co is for commit. In practice you cannot make a mess though, as the command line parameters between the two actions are very different, and the command will fail.

23Feb/0713

Video playback problems (black) after installing Beryl (or Compiz)

Note: Here we describe a workaround. The proper solution is to fix the graphics drivers and the X.Org X server. Such work is taking place, and for several cases you do not need this workaround. Especially with newer versions of Linux.

You just installed your 3D Linux desktop and you are really enthusiastic about it. But when you try to play some videos, you get a strange black output. What’s going on?
The common software video players that come with the Linux desktop are able to display the video stream to several types of output devices. This includes several types of output for the graphical interface, and also obscure output devices such as text mode, using ASCII characters.
The default output device is XVideo (or Xv) for players such as those based on GStreamer (totem) and VLC.
As you guessed, there is a bug with XVideo when using Beryl/Compiz. Therefore, to fix, you need to switch to another output device that works.
For GStreamer players (such as totem, the default movie player in GNOME, Ubuntu and so on), you need to run from the command line the command
gstreamer-properties
(with older distributions such as Ubuntu 6.06 there is an option in System/Preferences for this).
and pick
Video, then for Default Video Plugin choose X Window System (No Xv). Click on test to verify that it actually works. Click Close and you are set.
VLC is not installed by default in Ubuntu 6.10. You need to install manually using the Synaptic Package Manager (under System/Administration), once you have activated the Universe repository in Repositories.
Start VLC and click on Settings, then Preferences. Expand Video and then expand Output modules. You will notice several options for output device. How do we actually choose which one should be the active output device? Well, it appears it’s a bit tricky. Select the item Output modules, and notice the checkbox at the bottom right that says Advanced options. Check the box, and now you have the option to select a different output device. Pick X11 video output, click on Save and you are set!

Update (17 Jun 2007): Added section at UbuntuGuide.org, How do I fix black windows during video playback.

9Jun/061

How to easily modify a program in your Ubuntu?

Suppose we want to change the functionality of an Ubuntu application but we do not want to go into all the trouble of finding the source code, installing in /usr/local/, breaking dependencies with original versions and so on.

Let’s change Character Map (gucharmap), and specifically change the default font size from 20pt to 14pt, so that when you start it there is more space in the character window. Currently Character Map does not offer an option to save this setting.

We get the source code of Character Map,

# apt-get source gucharmap

Then,

cd gucharmap-1.4.4/

and now we edit the file gucharmap/main.c

We know what to edit because we visited the GNOME CVS Website, at http://cvs.gnome.org/viewcvs/gucharmap/

and we examined the logs for the file http://cvs.gnome.org/viewcvs/gucharmap/gucharmap/main.c?view=log

which show that for Revision 1.69, the following change took place,

Log:

2004-02-01  Noah Levitt

* gucharmap/gucharmap-table.c: Improve square size.

* gucharmap/main.c: Increase default font size.

When we click on the link Diff to previous 1.68 of the above page, we pinpoint the change,

version 1.68, Sun Feb 1 03:46:21 2004 UTC version 1.69, Mon Feb 2 00:48:05 2004 UTC
Line 93 main (gint argc, gchar **argv)
Line 93 main (gint argc, gchar **argv)

gint default_size = PANGO_PIXELS (1.5 * pango_font_description_get_size (window->style->font_desc));

gint default_size = PANGO_PIXELS (2.0 * pango_font_description_get_size (window->style->font_desc));

The change in the multiplier (from 1.5 to 2.0) changes the font size from 15pt to 20pt.

20pt is too big for us, therefore we edit the file gucharmap/main.c and change the 2.0 to 1.4 (14pt).
At this point we can compile the package using the command line

$ dpkg-buildpackage -rfakeroot -uc -b

dpkg-buildpackage: source package is gucharmap
dpkg-buildpackage: source version is 1:1.4.4-1ubuntu1
dpkg-buildpackage: source changed by Sebastien Bacher
dpkg-buildpackage: host architecture i386
fakeroot debian/rules clean

……….

At this point it is possible that you will get an error that an essential package is missing. The above command line will name the missing files, therefore you can simply install by

# apt-get install package-name

In case you do not have the basic compiler packages, you would need to install the build-essential meta-package. Do

# apt-get install build-essential

Finally, after the dpkg-buildpackage command completes, it will create one or more .deb packages in the directory above gucharmap.

# cd ..

# ls -l *.deb

gucharmap_1.4.4-1ubuntu1_i386.deb

libgucharmap4_1.4.4-1ubuntu1_i386.deb

libgucharmap4-dev_1.4.4-1ubuntu1_i386.deb
#

You can now install them (over the original packages) by running

# dpkg -i gucharmap_1.4.4-1ubuntu1_i386.deb libgucharmap4_1.4.4-1ubuntu1_i386.deb libgucharmap4-dev_1.4.4-1ubuntu1_i386.deb

Now we start the Character Map from Applications/Accessories/ and we get the default character size of 14pt!

Is there something we should pay attention on top of this? Yes, we should investigate the GNOME Bugzilla in case there is relevant work on this issue. We visit

http://bugzilla.gnome.org/

and specifically we click on the link Browse.

There, we select the package gucharmap (how do we know that Character Map is gucharmap? We either click on Help/About in Character Map which shows the internal name, or we run ps ax at a Applications/Accessories/Terminal while Character Map is running; the name gucharmap will pop up at the end of the long list.).

gucharmap is under the Desktop heading in the Browse list; or click on this direct link of bug reports on gucharmap.
If you start perusing the gucharmap bugs list, you will notice Bug #140414, titled remember settings. This report describes a superset of the problem we tried to solve above. That is, the bug report asks to enable Character Map to use the GNOME configuration database (gconf) so that it saves/remembers the user settings. However, this specific bug report is still pending.

The correct way to solve the configuration settings issue of gucharmap is to implement what is described in Bug #140414. If you have Ubuntu 6.06, you most likely have a very recent version of the source code of gucharmap. Therefore, the differences would be rather minimal. You can give it a go and try to get the gconf functionality in place.

You compile, install and test. If it works, you can make a patch of your changes; visit another directory and download a fresh copy of the source code using the apt-get source packagename command. Rename gucharmap-1.4.4 to gucharmap-1.4.4.ORIGINAL

# mv gucharmap-1.4.4 gucharmap-1.4.4.ORIGINAL

and make sure you clean the original gucharmap-1.4.4/ directory from compiled files (enter the directory were you did the source code changes and run make clean).

Finally, create a diff file,

# diff -ur ~/tmp/gucharmap-1.4.4.ORIGINAL ~/gucharmap-1.4.4/ > remember-settings.patch

In ideal terms, it is preferable if you could produce a patch for the latest version of gucharmap. That is, the version of gucharmap you get from http://cvs.gnome.org/viewcvs/gucharmap/. By doing so, the developers will love you because they will be able to simply apply the patch and limit the burden of adding the feature. Indeed, if it is too much effort to get a build system running, you can start off with simple patches and if you feel you are doing well with it, make the extra mile to have a build system. More on this in a future post.

   

Switch to our mobile site