https://wiki.archlinux.org/api.php?action=feedcontributions&user=M3tr0g33k&feedformat=atomArchWiki - User contributions [en]2024-03-28T15:09:39ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Xterm&diff=63546Xterm2009-03-02T07:49:23Z<p>M3tr0g33k: /* Making it work */</p>
<hr />
<div>[[Category:Eye candy (English)]]<br />
[[Category:Desktop environments (English)]]<br />
<br />
== Introduction ==<br />
Using openbox, it is as yet impossible to automatically apply transparency to a window as it opens.<br />
This is a way of automatically applying tranparency to an opening xterm using transset-df.<br />
It uses a trick of running a script as you start the xterm which then runs another script which calls transset-df.<br />
The reason that it is so complicated, is that to run transet-df on the new xterm window as it opens, we need the XWINDOWID value for the window.<br />
<br />
The three steps which happen to run transset-df on an opening xterm are:<br />
<br />
* Start xterm<br />
* Run a script which executes a command, then starts a bash shell<br />
** (This step is necessary because when you open an xterm with 'xterm -e' the command is executed and then the xterm closes. This is not what we want.)<br />
* Run a script which finds the XWINDOWID of the current xterm and passes it to transset-df to set the transparency<br />
<br />
== Making it work ==<br />
Make a script in (for instance) /usr/local/bin called '''pre-exec'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
${*}<br />
exec /bin/bash<br />
<br />
Make a script in (for instance) /usr/local/bin called '''fader'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
transset-df -i `set | grep WINDOWID | awk 'BEGIN { FS = "=" } ; { print $2 }'` $1 >/dev/null 2>&1<br />
<br />
When you want an xterm to open with a transparency level of 70%, call:<br />
<br />
xterm -geom 80x50 -T xterm -e /usr/local/bin/pre-exec /usr/local/bin/fader 0.7 &<br />
<br />
I have put this line in my .config/openbox/menu.xml file so I always get a transparent xterm.<br />
<br />
== Explanation ==<br />
=== How this doesn't work ===<br />
There is some discussion on how to get the correct process id for a launched program.<br />
When a shell (in this case gnu bash) is running, it's process id (PID) is found by: <br />
echo $$<br />
The last process put into the background (like xterm&) is found by:<br />
echo $!<br />
So, you think - why all this trouble to get the PID of an xterm? Surely you can simply get the PID by doing:<br />
xterm & ; echo $!<br />
And if you do this at the command line, then this works. You get the PID of the xterm and you can then find the XWINDOWID of the xterm to pass to transset-df. All is well. But who is running xterm when you start it from a menu?<br />
The answer is not obvious. If you try to use the $! that is valid in the menu scope, you turn the ''previous'' xterm transparent, not the one you just started.<br />
<br />
=== How this works ===<br />
The pre-exec script does two things:<br />
* run the commands passed to it in the xterm's bash shell<br />
* start a new bash shell<br />
The magic comes from <br />
${*}<br />
which just passes everything on the command line of the script (pre-exec) to the shell which is started because you used the '''-e''' directive. If this was all that happened, then the xterm would immediately exit. But we start a new interactive shell<br />
/bin/bash<br />
which takes control so there is still an interactive prompt alive in the xterm.<br />
<br />
That is quite clever, because it leaves a gap between when the xterm is started with an active shell and when the interactive shell is started up.<br />
In that gap, you can run anything you want that needs the same environment as the later interactive shell, but which needs doing before the interactive shell starts. (NB this is a lot like putting something in a .profile or .bashrc file, which will be executed before the interactive prompt when you start a bash shell.)<br />
<br />
When the xterm starts its bash shell to execute the '''pre-exec''' script, the automatic environment initialization sets variables like XWINDOWID. The '''fader''' script looks up the XWINDOWID and passes it to transset-df along with the command line argument for the transparency. This command finishes, the new bash shell is started and the shell started by '''-e''' exits, leaving you at a bash prompt.<br />
<br />
== Links ==<br />
Tried to find the source links for my working on this and they have gone away.<br />
Thanks and qudos to all those whose work I've leeched to get this working!<br />
<br />
== Problems with this approach ==<br />
Your new transparent xterm is called '''pre-exec'''. This can be changed - someone let us all know how :)<br />
[edit] Use '-T xterm' on the command line to keep the window called 'xterm'.</div>M3tr0g33khttps://wiki.archlinux.org/index.php?title=Xterm&diff=63545Xterm2009-03-02T07:47:29Z<p>M3tr0g33k: /* Problems with this approach */</p>
<hr />
<div>[[Category:Eye candy (English)]]<br />
[[Category:Desktop environments (English)]]<br />
<br />
== Introduction ==<br />
Using openbox, it is as yet impossible to automatically apply transparency to a window as it opens.<br />
This is a way of automatically applying tranparency to an opening xterm using transset-df.<br />
It uses a trick of running a script as you start the xterm which then runs another script which calls transset-df.<br />
The reason that it is so complicated, is that to run transet-df on the new xterm window as it opens, we need the XWINDOWID value for the window.<br />
<br />
The three steps which happen to run transset-df on an opening xterm are:<br />
<br />
* Start xterm<br />
* Run a script which executes a command, then starts a bash shell<br />
** (This step is necessary because when you open an xterm with 'xterm -e' the command is executed and then the xterm closes. This is not what we want.)<br />
* Run a script which finds the XWINDOWID of the current xterm and passes it to transset-df to set the transparency<br />
<br />
== Making it work ==<br />
Make a script in (for instance) /usr/local/bin called '''pre-exec'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
${*}<br />
exec /bin/bash<br />
<br />
Make a script in (for instance) /usr/local/bin called '''fader'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
transset-df -i `set | grep WINDOWID | awk 'BEGIN { FS = "=" } ; { print $2 }'` $1 >/dev/null 2>&1<br />
<br />
When you want an xterm to open with a transparency level of 80%, call:<br />
<br />
xterm -e pre-exec fader 0.8 &<br />
<br />
I have put this line in my .config/openbox/menu.xml file so I always get a transparent xterm.<br />
<br />
== Explanation ==<br />
=== How this doesn't work ===<br />
There is some discussion on how to get the correct process id for a launched program.<br />
When a shell (in this case gnu bash) is running, it's process id (PID) is found by: <br />
echo $$<br />
The last process put into the background (like xterm&) is found by:<br />
echo $!<br />
So, you think - why all this trouble to get the PID of an xterm? Surely you can simply get the PID by doing:<br />
xterm & ; echo $!<br />
And if you do this at the command line, then this works. You get the PID of the xterm and you can then find the XWINDOWID of the xterm to pass to transset-df. All is well. But who is running xterm when you start it from a menu?<br />
The answer is not obvious. If you try to use the $! that is valid in the menu scope, you turn the ''previous'' xterm transparent, not the one you just started.<br />
<br />
=== How this works ===<br />
The pre-exec script does two things:<br />
* run the commands passed to it in the xterm's bash shell<br />
* start a new bash shell<br />
The magic comes from <br />
${*}<br />
which just passes everything on the command line of the script (pre-exec) to the shell which is started because you used the '''-e''' directive. If this was all that happened, then the xterm would immediately exit. But we start a new interactive shell<br />
/bin/bash<br />
which takes control so there is still an interactive prompt alive in the xterm.<br />
<br />
That is quite clever, because it leaves a gap between when the xterm is started with an active shell and when the interactive shell is started up.<br />
In that gap, you can run anything you want that needs the same environment as the later interactive shell, but which needs doing before the interactive shell starts. (NB this is a lot like putting something in a .profile or .bashrc file, which will be executed before the interactive prompt when you start a bash shell.)<br />
<br />
When the xterm starts its bash shell to execute the '''pre-exec''' script, the automatic environment initialization sets variables like XWINDOWID. The '''fader''' script looks up the XWINDOWID and passes it to transset-df along with the command line argument for the transparency. This command finishes, the new bash shell is started and the shell started by '''-e''' exits, leaving you at a bash prompt.<br />
<br />
== Links ==<br />
Tried to find the source links for my working on this and they have gone away.<br />
Thanks and qudos to all those whose work I've leeched to get this working!<br />
<br />
== Problems with this approach ==<br />
Your new transparent xterm is called '''pre-exec'''. This can be changed - someone let us all know how :)<br />
[edit] Use '-T xterm' on the command line to keep the window called 'xterm'.</div>M3tr0g33khttps://wiki.archlinux.org/index.php?title=Xterm&diff=62981Xterm2009-02-24T15:53:51Z<p>M3tr0g33k: /* How this works */</p>
<hr />
<div>[[Category:Eye candy (English)]]<br />
[[Category:Desktop environments (English)]]<br />
<br />
== Introduction ==<br />
Using openbox, it is as yet impossible to automatically apply transparency to a window as it opens.<br />
This is a way of automatically applying tranparency to an opening xterm using transset-df.<br />
It uses a trick of running a script as you start the xterm which then runs another script which calls transset-df.<br />
The reason that it is so complicated, is that to run transet-df on the new xterm window as it opens, we need the XWINDOWID value for the window.<br />
<br />
The three steps which happen to run transset-df on an opening xterm are:<br />
<br />
* Start xterm<br />
* Run a script which executes a command, then starts a bash shell<br />
** (This step is necessary because when you open an xterm with 'xterm -e' the command is executed and then the xterm closes. This is not what we want.)<br />
* Run a script which finds the XWINDOWID of the current xterm and passes it to transset-df to set the transparency<br />
<br />
== Making it work ==<br />
Make a script in (for instance) /usr/local/bin called '''pre-exec'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
${*}<br />
exec /bin/bash<br />
<br />
Make a script in (for instance) /usr/local/bin called '''fader'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
transset-df -i `set | grep WINDOWID | awk 'BEGIN { FS = "=" } ; { print $2 }'` $1 >/dev/null 2>&1<br />
<br />
When you want an xterm to open with a transparency level of 80%, call:<br />
<br />
xterm -e pre-exec fader 0.8 &<br />
<br />
I have put this line in my .config/openbox/menu.xml file so I always get a transparent xterm.<br />
<br />
== Explanation ==<br />
=== How this doesn't work ===<br />
There is some discussion on how to get the correct process id for a launched program.<br />
When a shell (in this case gnu bash) is running, it's process id (PID) is found by: <br />
echo $$<br />
The last process put into the background (like xterm&) is found by:<br />
echo $!<br />
So, you think - why all this trouble to get the PID of an xterm? Surely you can simply get the PID by doing:<br />
xterm & ; echo $!<br />
And if you do this at the command line, then this works. You get the PID of the xterm and you can then find the XWINDOWID of the xterm to pass to transset-df. All is well. But who is running xterm when you start it from a menu?<br />
The answer is not obvious. If you try to use the $! that is valid in the menu scope, you turn the ''previous'' xterm transparent, not the one you just started.<br />
<br />
=== How this works ===<br />
The pre-exec script does two things:<br />
* run the commands passed to it in the xterm's bash shell<br />
* start a new bash shell<br />
The magic comes from <br />
${*}<br />
which just passes everything on the command line of the script (pre-exec) to the shell which is started because you used the '''-e''' directive. If this was all that happened, then the xterm would immediately exit. But we start a new interactive shell<br />
/bin/bash<br />
which takes control so there is still an interactive prompt alive in the xterm.<br />
<br />
That is quite clever, because it leaves a gap between when the xterm is started with an active shell and when the interactive shell is started up.<br />
In that gap, you can run anything you want that needs the same environment as the later interactive shell, but which needs doing before the interactive shell starts. (NB this is a lot like putting something in a .profile or .bashrc file, which will be executed before the interactive prompt when you start a bash shell.)<br />
<br />
When the xterm starts its bash shell to execute the '''pre-exec''' script, the automatic environment initialization sets variables like XWINDOWID. The '''fader''' script looks up the XWINDOWID and passes it to transset-df along with the command line argument for the transparency. This command finishes, the new bash shell is started and the shell started by '''-e''' exits, leaving you at a bash prompt.<br />
<br />
== Links ==<br />
Tried to find the source links for my working on this and they have gone away.<br />
Thanks and qudos to all those whose work I've leeched to get this working!<br />
<br />
== Problems with this approach ==<br />
Your new transparent xterm is called '''pre-exec'''. This can be changed - someone let us all know how :)</div>M3tr0g33khttps://wiki.archlinux.org/index.php?title=Xterm&diff=62980Xterm2009-02-24T15:52:00Z<p>M3tr0g33k: /* Explanation and links */</p>
<hr />
<div>[[Category:Eye candy (English)]]<br />
[[Category:Desktop environments (English)]]<br />
<br />
== Introduction ==<br />
Using openbox, it is as yet impossible to automatically apply transparency to a window as it opens.<br />
This is a way of automatically applying tranparency to an opening xterm using transset-df.<br />
It uses a trick of running a script as you start the xterm which then runs another script which calls transset-df.<br />
The reason that it is so complicated, is that to run transet-df on the new xterm window as it opens, we need the XWINDOWID value for the window.<br />
<br />
The three steps which happen to run transset-df on an opening xterm are:<br />
<br />
* Start xterm<br />
* Run a script which executes a command, then starts a bash shell<br />
** (This step is necessary because when you open an xterm with 'xterm -e' the command is executed and then the xterm closes. This is not what we want.)<br />
* Run a script which finds the XWINDOWID of the current xterm and passes it to transset-df to set the transparency<br />
<br />
== Making it work ==<br />
Make a script in (for instance) /usr/local/bin called '''pre-exec'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
${*}<br />
exec /bin/bash<br />
<br />
Make a script in (for instance) /usr/local/bin called '''fader'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
transset-df -i `set | grep WINDOWID | awk 'BEGIN { FS = "=" } ; { print $2 }'` $1 >/dev/null 2>&1<br />
<br />
When you want an xterm to open with a transparency level of 80%, call:<br />
<br />
xterm -e pre-exec fader 0.8 &<br />
<br />
I have put this line in my .config/openbox/menu.xml file so I always get a transparent xterm.<br />
<br />
== Explanation ==<br />
=== How this doesn't work ===<br />
There is some discussion on how to get the correct process id for a launched program.<br />
When a shell (in this case gnu bash) is running, it's process id (PID) is found by: <br />
echo $$<br />
The last process put into the background (like xterm&) is found by:<br />
echo $!<br />
So, you think - why all this trouble to get the PID of an xterm? Surely you can simply get the PID by doing:<br />
xterm & ; echo $!<br />
And if you do this at the command line, then this works. You get the PID of the xterm and you can then find the XWINDOWID of the xterm to pass to transset-df. All is well. But who is running xterm when you start it from a menu?<br />
The answer is not obvious. If you try to use the $! that is valid in the menu scope, you turn the ''previous'' xterm transparent, not the one you just started.<br />
<br />
=== How this works ===<br />
The pre-exec script does two things:<br />
* run the commands passed to it in the xterm's bash shell<br />
* start a new bash shell<br />
The magic comes from <br />
${*}<br />
which just passes everything on the command line of the script (pre-exec) to the shell which is started because you used the '''-e''' directive. If this was all that happened, then the xterm would immediately exit. But we start a new interactive shell<br />
/bin/bash<br />
which takes control so there is still an interactive prompt alive in the xterm.<br />
<br />
That is quite clever, because it leaves a gap between when the xterm is started with an active shell and when the interactive shell you are used to is started up.<br />
In that gap, you can run anything you want that needs the same environment as the later interactive shell, but which needs doing before the interactive shell starts. (NB this is a lot like putting something in a .profile or .bashrc file, which will be executed before the interactive prompt when you start a bash shell.)<br />
<br />
When the xterm starts its bash shell to execute the '''pre-exec''' script, the automatic environment initialisation puts sets variables like XWINDOWID. The '''fader''' script looks up the XWINDOWID and passes it to transset-df along with the command line argument for the transparency. This command finihes, the new bash shell is started and the shell started by '''-e''' exits.<br />
<br />
== Links ==<br />
Tried to find the source links for my working on this and they have gone away.<br />
Thanks and qudos to all those whose work I've leeched to get this working!<br />
<br />
== Problems with this approach ==<br />
Your new transparent xterm is called '''pre-exec'''. This can be changed - someone let us all know how :)</div>M3tr0g33khttps://wiki.archlinux.org/index.php?title=Xterm&diff=62979Xterm2009-02-24T15:47:17Z<p>M3tr0g33k: /* How this works */</p>
<hr />
<div>[[Category:Eye candy (English)]]<br />
[[Category:Desktop environments (English)]]<br />
<br />
== Introduction ==<br />
Using openbox, it is as yet impossible to automatically apply transparency to a window as it opens.<br />
This is a way of automatically applying tranparency to an opening xterm using transset-df.<br />
It uses a trick of running a script as you start the xterm which then runs another script which calls transset-df.<br />
The reason that it is so complicated, is that to run transet-df on the new xterm window as it opens, we need the XWINDOWID value for the window.<br />
<br />
The three steps which happen to run transset-df on an opening xterm are:<br />
<br />
* Start xterm<br />
* Run a script which executes a command, then starts a bash shell<br />
** (This step is necessary because when you open an xterm with 'xterm -e' the command is executed and then the xterm closes. This is not what we want.)<br />
* Run a script which finds the XWINDOWID of the current xterm and passes it to transset-df to set the transparency<br />
<br />
== Making it work ==<br />
Make a script in (for instance) /usr/local/bin called '''pre-exec'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
${*}<br />
exec /bin/bash<br />
<br />
Make a script in (for instance) /usr/local/bin called '''fader'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
transset-df -i `set | grep WINDOWID | awk 'BEGIN { FS = "=" } ; { print $2 }'` $1 >/dev/null 2>&1<br />
<br />
When you want an xterm to open with a transparency level of 80%, call:<br />
<br />
xterm -e pre-exec fader 0.8 &<br />
<br />
I have put this line in my .config/openbox/menu.xml file so I always get a transparent xterm.<br />
<br />
== Explanation and links ==<br />
Tried to find the source links for my working on this and they have gone away.<br />
Thanks and qudos to all those whose work I've leeched to get this working!<br />
<br />
=== How this doesn't work ===<br />
There is some discussion on how to get the correct process id for a launched program.<br />
When a shell (in this case gnu bash) is running, it's process id (PID) is found by: <br />
echo $$<br />
The last process put into the background (like xterm&) is found by:<br />
echo $!<br />
So, you think - why all this trouble to get the PID of an xterm? Surely you can simply get the PID by doing:<br />
xterm & ; echo $!<br />
And if you do this at the command line, then this works. You get the PID of the xterm and you can then find the XWINDOWID of the xterm to pass to transset-df. All is well. But who is running xterm when you start it from a menu?<br />
The answer is not obvious. If you try to use the $! that is valid in the menu scope, you turn the ''previous'' xterm transparent, not the one you just started.<br />
<br />
=== How this works ===<br />
The pre-exec script does two things:<br />
* run the commands passed to it in the xterm's bash shell<br />
* start a new bash shell<br />
The magic comes from <br />
${*}<br />
which just passes everything on the command line of the script (pre-exec) to the shell which is started because you used the '''-e''' directive. If this was all that happened, then the xterm would immediately exit. But we start a new interactive shell<br />
/bin/bash<br />
which takes control so there is still an interactive prompt alive in the xterm.<br />
<br />
That is quite clever, because it leaves a gap between when the xterm is started with an active shell and when the interactive shell you are used to is started up.<br />
In that gap, you can run anything you want that needs the same environment as the later interactive shell, but which needs doing before the interactive shell starts. (NB this is a lot like putting something in a .profile or .bashrc file, which will be executed before the interactive prompt when you start a bash shell.)<br />
<br />
When the xterm starts its bash shell to execute the '''pre-exec''' script, the automatic environment initialisation puts sets variables like XWINDOWID. The '''fader''' script looks up the XWINDOWID and passes it to transset-df along with the command line argument for the transparency. This command finihes, the new bash shell is started and the shell started by '''-e''' exits.<br />
<br />
== Problems with this approach ==<br />
Your new transparent xterm is called '''pre-exec'''. This can be changed - someone let us all know how :)</div>M3tr0g33khttps://wiki.archlinux.org/index.php?title=Xterm&diff=62978Xterm2009-02-24T15:35:20Z<p>M3tr0g33k: /* Explanation and links */</p>
<hr />
<div>[[Category:Eye candy (English)]]<br />
[[Category:Desktop environments (English)]]<br />
<br />
== Introduction ==<br />
Using openbox, it is as yet impossible to automatically apply transparency to a window as it opens.<br />
This is a way of automatically applying tranparency to an opening xterm using transset-df.<br />
It uses a trick of running a script as you start the xterm which then runs another script which calls transset-df.<br />
The reason that it is so complicated, is that to run transet-df on the new xterm window as it opens, we need the XWINDOWID value for the window.<br />
<br />
The three steps which happen to run transset-df on an opening xterm are:<br />
<br />
* Start xterm<br />
* Run a script which executes a command, then starts a bash shell<br />
** (This step is necessary because when you open an xterm with 'xterm -e' the command is executed and then the xterm closes. This is not what we want.)<br />
* Run a script which finds the XWINDOWID of the current xterm and passes it to transset-df to set the transparency<br />
<br />
== Making it work ==<br />
Make a script in (for instance) /usr/local/bin called '''pre-exec'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
${*}<br />
exec /bin/bash<br />
<br />
Make a script in (for instance) /usr/local/bin called '''fader'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
transset-df -i `set | grep WINDOWID | awk 'BEGIN { FS = "=" } ; { print $2 }'` $1 >/dev/null 2>&1<br />
<br />
When you want an xterm to open with a transparency level of 80%, call:<br />
<br />
xterm -e pre-exec fader 0.8 &<br />
<br />
I have put this line in my .config/openbox/menu.xml file so I always get a transparent xterm.<br />
<br />
== Explanation and links ==<br />
Tried to find the source links for my working on this and they have gone away.<br />
Thanks and qudos to all those whose work I've leeched to get this working!<br />
<br />
=== How this doesn't work ===<br />
There is some discussion on how to get the correct process id for a launched program.<br />
When a shell (in this case gnu bash) is running, it's process id (PID) is found by: <br />
echo $$<br />
The last process put into the background (like xterm&) is found by:<br />
echo $!<br />
So, you think - why all this trouble to get the PID of an xterm? Surely you can simply get the PID by doing:<br />
xterm & ; echo $!<br />
And if you do this at the command line, then this works. You get the PID of the xterm and you can then find the XWINDOWID of the xterm to pass to transset-df. All is well. But who is running xterm when you start it from a menu?<br />
The answer is not obvious. If you try to use the $! that is valid in the menu scope, you turn the ''previous'' xterm transparent, not the one you just started.<br />
<br />
=== How this works ===<br />
The pre-exec script does two things:<br />
* run the commands passed to it in a bash shell<br />
* start a new bash shell</div>M3tr0g33khttps://wiki.archlinux.org/index.php?title=Xterm&diff=62679Xterm2009-02-20T11:54:17Z<p>M3tr0g33k: New page: Category:Eye candy (English) Category:Desktop environments (English) == Introduction == Using openbox, it is as yet impossible to automatically apply transparency to a window as i...</p>
<hr />
<div>[[Category:Eye candy (English)]]<br />
[[Category:Desktop environments (English)]]<br />
<br />
== Introduction ==<br />
Using openbox, it is as yet impossible to automatically apply transparency to a window as it opens.<br />
This is a way of automatically applying tranparency to an opening xterm using transset-df.<br />
It uses a trick of running a script as you start the xterm which then runs another script which calls transset-df.<br />
The reason that it is so complicated, is that to run transet-df on the new xterm window as it opens, we need the XWINDOWID value for the window.<br />
<br />
The three steps which happen to run transset-df on an opening xterm are:<br />
<br />
* Start xterm<br />
* Run a script which executes a command, then starts a bash shell<br />
** (This step is necessary because when you open an xterm with 'xterm -e' the command is executed and then the xterm closes. This is not what we want.)<br />
* Run a script which finds the XWINDOWID of the current xterm and passes it to transset-df to set the transparency<br />
<br />
== Making it work ==<br />
Make a script in (for instance) /usr/local/bin called '''pre-exec'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
${*}<br />
exec /bin/bash<br />
<br />
Make a script in (for instance) /usr/local/bin called '''fader'''. Make sure you have execute permission for everyone. The script is:<br />
<br />
transset-df -i `set | grep WINDOWID | awk 'BEGIN { FS = "=" } ; { print $2 }'` $1 >/dev/null 2>&1<br />
<br />
When you want an xterm to open with a transparency level of 80%, call:<br />
<br />
xterm -e pre-exec fader 0.8 &<br />
<br />
I have put this line in my .config/openbox/menu.xml file so I always get a transparent xterm.<br />
<br />
== Explanation and links ==<br />
To do...</div>M3tr0g33k