Well, I have the solution now =)

---

Vous vous souvenez de mon billet sur alt et xterm ?

Et bien j'ai la solution ! =)

If you search for altsendsescape on the web, you will find a lot of solutions, saying that you have to edit your .Xdefault or .Xresources with something like:
XTerm*altSendsEscape: true
or *VT100*altSendsEscape: 1

I'm sure they are all good, but none were working with me: altSendsEscape wasn't checked in the menu... So I went for XTerm*metaSendsEscape: true and this, it was checked. But I had to do a little trick to be able to type alt+. correctly. Also add in .Xdefault:
XTerm*eightBitInput: false

I still don't know why, but it works now =)

---

Si vous cherchez altsendsescape sur le net, il y a plein de solutions, disant qu'il faut éditer son .Xdefault ou son .Xresources avec quelque chose gu genre :
XTerm*altSendsEscape: true
ou *VT100*altSendsEscape: 1

Je suis sûr que tous marchent bien, mais aucun ne marchait pour moi : altSendsEscape n'était pas coché dans le menu menu... Du coup je suis allé pour XTerm*metaSendsEscape: true et ça, c'était bien coché. Mais j'ai dû ajouter une petite ligne en plus dans .Xdefault pour pouvoir faire alt+. :
XTerm*eightBitInput: false

Je ne sais toujours pas pourquoi, mais ça marche =)

Again, as a reminder, because I spend so much time to find the solution which was simple, modifying my .inputrc, .bashrc, ...

When you hit for example alt+. in a terminal, you should have the last argument of the last command.
In my xterm, it didn't work and I had to hit Esc then . (I know, it's not so terrible, but habits...).

What should you do to map alt to meta ? Press Ctrl, then left-click in the terminal and choose “alt sends escape”...

Now, I will try to find how to save this behaviour to be the default one ;)

---

おひさしぶり (ohisashiburi : ça fait un bail) !!

Encore un pense-bête parce que j'ai passé tellement de temps pour trouver la solution qui est tellement simple, à réécrire mes .inputrc, .bashrc...

Quand on tape par exemple alt+. dans un terminal, on doit avoir le dernier argument de la dernière commande.
Dans mon xterm, ça ne marchait pas et je devais utiliser Esc puis . (pas si compliqué que ça, mais les habitudes...).

Que faire pour mapper alt à meta ? Appuyer sur Ctrl, puis clic gauche dans le terminal et choisir « alt sends escape » ...

Maintenant, il me reste à trouver comment sauver ça par défaut ;)

This isn't a solution I came up with, but I did have to search through a few web pages before finding a set of steps that would work -- the credit really goes to all those, especially this post on the cygwin mailing lists: http://cygwin.com/ml/cygwin-xfree/2007-03/msg00011.html

If you've installed Cygwin and MingW (X Server), and try to get an xterm to show up, but are having either no luck or only occasional luck and the following error

45 [main] xterm 2240 child_copy: linked dll data write copy failed,
0x3AB0
0..0x3AB440, done 0, windows pid 2356, Win32 error 487
xterm: Error 29, errno 11: Resource temporarily unavailable
Reason: spawn: fork() failed

The solution is to use the rebase package that Cygwin installs. As the post above reads, error 487 is a classic indicator of a DLL address space collision.

From the rebase README:

1. shutdown all Cygwin processes and services
2. start ash (do not use bash or rxvt)
3. execute /bin/rebaseall (in the ash window)

After that, you should be able to run xterm. Don't forget to set your DISPLAY variable (usually, something like DISPLAY=localhost:0.0). I do recommend reading the above post for additional background, and the rebase README -- but these are your quick steps to recovery.

What I discovered was xwd and ImageMagick. I was able to easily write a one line mini-script to take shots of single windows; however, the limitations of such an implementation were evident.

First, it would not be something for an everyday, average user. Second, there was no method of error reporting. Of course, the only real errors possible with something like this are missing dependencies, and while this script does not (currently) check specifically for the utilities it relies on, it does give an error, and generally any error from this script means missing dependencies. Third, there was no command-line argument support. Fourth, there was no usage documentation or help.

So I decided to write the script again, this time with these limitations in mind. There are still several limitations, such as the inability to check for specific dependencies, but those features will make it in with time.

You can visit the project's page here on my WordPress site.

Features

The features of the shell prompt are important to note. I had a specific goal: I wanted to display my system information in a friendly manner. Simple, huh? So here's a break down!

• Display System Information
• Create a container to go around the system information
• Format the text of the system information to be visually appealing
• Use various colors to differentiate the various parts of the system information
• Color code the actual prompt to make identifying information easier

Pretty basic, huh? It's not a very large feature list, but since I decided to tackle this as my first BASH experience (as far as scripting goes), it quickly became a behemoth project that took around two to three hours to figure out. Resources were few and far in between, and those that existed typically didn't have exactly the information I needed.

Download

First, you can download my .bashrc file if you simply want the exact same thing that I use without doing it yourself, or if you just want a starting place. Grab it here.

Colors, Colors Everywhere!

Bash actually has a small number of colors. It's pretty limited. And for some reason, the escape sequences for the prompt and for BASH itself are different. I'm not sure why, and I never did find a resource that told me this. I spent most of my time developing this on figuring out that difference. A table of the proper color codes follows.

Black       0;30     Dark Gray     1;30
Blue        0;34     Light Blue    1;34
Green       0;32     Light Green   1;32
Cyan        0;36     Light Cyan    1;36
Red         0;31     Light Red     1;31
Purple      0;35     Light Purple  1;35
Brown       0;33     Yellow        1;33
Light Gray  0;37     White         1;37

Now, if you open up my .bashrc file, you'll notice that I don't just use the codes alone. They require special escape sequences to surround them to tell BASH that they're non-printing. The characters are \[33[ and \]. So, between those two, you insert your color code. Then, follow it with an m. The m is for colors only. If you wanted purple, for example, it would be \[33[0;35m\].

Now that you understand how to CREATE the colors, it's time to plug them in! We're only working on the prompt right now; the system information will come later.

The BASH Prompt

If you don't have the variable PS1 in your .bashrc file, create it at the bottom now. Remember that this is Linux, and everything is case sensitive. PS1 is, more or less, what your shell prompt looks like. It's important to set up a few basics immediately. First, you'll want your username displayed, or so I would imagine. So bring your PS1 variable to look like this:

PS1="\u"

This simply tells BASH to display your username. Not very effective, and if you were to save, exit, and restart your terminal, it would be pretty ugly and confusing. So let's add a little separation. Change PS1 to mirror the following code:

PS1="[ \u ]$ "

This will display your username again, this time enclosed by square brackets, then followed by the $ symbol. We use this symbol to help differentiate between a normal user and root. You can use whatever symbol you'd like (if you even want a symbol), but the dollar sign is used as convention. It's still not very interesting though, is it? Next, we're going to tackle something very common and important. What if you use multiple Linux systems? It's not an issue if you're physically at the machine; chances are you know which one it is. Sometimes, though, if you're in a lab, you might not. I certainly wouldn't. So it's important to have the hostname of the machine displayed also. To separate the username from the hostname, I'm going to use the @ symbol, again because it is fairly standard. So now change your PS1 variable to read like mine:

PS1="[ \u@\h ]$ "

Now the problem is that you're not sure which directory you're in. You have two options here: the full directory (\w) or the current base directory only (\W). If you can't tell the difference, the full directory is a lower-case w and the current base directory is an upper-case W. I'll leave this up to you. Place it wherever you'd like.

Now for colors. Remember color codes have to be enclosed with special characters: \[33[ and \]. So if you want the information about which user is using the shell, the hostname, and the base directory to be purple and all of the commands entered to be cyan, you could do the following:

PS1="\[33[0;35m\][ \u@\h W ]$ \[33[0;36m\]"

Those are terrible colors, but you get the idea. Another idea is to put the color codes into variables, as I have done. They're descriptive and aid in reuse if you want to use more colors. Play around with things a bit. There are more prompt escape sequences to display different information, but I'm not going to list them all; Google is your friend!

Displaying System Information

This is only going to cover how to actually display the information; formatting it and coloring it is up to you.

Displaying the information is fairly simple. Store commands in variables. The basic syntax to do this is:

variable_name="$(command_name)";

Note the $() that must surround your command. There is another syntactical option, but it's messy and confusing so I won't show it. This method of enclosing your commands is used very often in BASH, so commit it to memory if you plan on doing further BASH work.

Some basic commands to grab system information are id -un, id -u, uname -r, and cat /etc/issue. Anything more advanced is up to you. Discovering what the aforementioned commands is also up to you; if you don't do it, you won't learn it!

Now you should note that the escape sequences required to show color for the prompt are not the same as they are for actual BASH output. So what needs to enclose the color codes for simple BASH output? 33[. That's it. And it only goes at the beginning. MUCH easier.

The End

That's it! I hope it's helped you at least a little. If you have any questions, let me know!

Xcursor.theme: DMZ
Xcursor.size: 24


Wir schauen in die Manpage von xterm man xterm und gucken uns die Möglichkeiten an:
man xterm

Unser neues xterm soll größer...

-fn 10x20 -geometry 150x50

...schöner...

-bg black -fg white

...mit Scrollbar und mehr Inhalt...

-sb -sl 1000

...und visuellem Feedback erscheinen:

-vb

Voila:

xterm -fn 10x20 -geometry 150x50 -bg black -fg white -sb -sl 1000 -vb

Zugegeben ist die font size doch ein bisschen groß geraten. Ich bleibe beim default :)

Há muito tempo eu evitava ao máximo usar o Xterm (emulador de terminal do X) por causa de sua aparência, principalmente pelas fontes pequenas e serrilhadas. Recentemente, tive alguns problemas com o XFCE Terminal no Debian SID e tive que apelar para o Xterm. Como estou com tempo disponível, fui procurar algumas dicas para torná-lo mais apresentável.

Em alguns segundos achei um excelente artigo da Comunidade LinuxBSD falando sobre personalização do Xterm, incluindo alterações no tamanho das fontes, cores e a tão bela suavização de fontes. Para quem quer conferir o artigo, siga este apontador.

Não tem abas nem recursos muito avançados, mas o resultado é muito bom:

:~)

Do Debian Etch