will rxvt have pseudo transparency?

[tobiaus]

i know it is a stupid, pointless feature (easier to make a case for real transparency) but it always made a distro almost devoid of candy (i prefer it simple too) look a little more modern- even if pseudo-transparency has been around for a long time.

i used rxvt a long time ago and i thought aterm performed better (perception of daily use.) i don't think i'll like adjusting to rxvt again (and i don't think i'll probably bother installing aterm as an extension, though i hope somebody will create one) but so long as this is the effort to save a few k, i'd like to know if there are any other advantages to rxvt, so i can feel better about using it instead. (and even if it is stupid, keeping pseudo transparency would help, if it has it.)

[curaga]

It does have transparency, but unlike aterm, it's slow, and has no shading.
But the size difference is well worth it.

[mikshaw]

I thought it doesn't have transparency.  That was one reason I switched to using aterm in DSL back when it used rxvt.  There was also another reason, although it may not apply to TC base (maybe only if you're using Bash)

After a small annoyance with rxvt today I started wondering if perhaps aterm might be a better choice for a DSL x terminal.  I don't hate rxvt, but I'm beginning to wonder if it really beats aterm with a size/features ratio.

Let's consider the pros and cons of each...

rxvt:  Arguably the smallest x terminal available, at 82k.
Uses very little ram.
Depends on only 3 external libs.

aterm: Not as small as rxvt, at 112k.
Difference in ram use is nearly nil....something like 30 bytes (or was that kb?)
Twice as many libs needed, though all are available in DSL.
Has transparency.

One thing (apart from the transparency) that I think really puts aterm over rxvt is what I think is a bug in rxvt.  It would not properly read an environment variable exported from .bash_profile unless it was launched as a login shell.  I tested this out to make sure that aterm wasn't being run as login by issuing a command from .bash_profile.  Neither term registered the command, as it should be unless run as a login shell.  However, exporting a variable from .bash_profile should affect all subsequent shells, login or not, but rxvt did not accept it until I exported that variable from one shell and then launched rxvt from the same shell.  Aterm had no trouble reading the variable.

So maybe it's something to think about....is a few extra K's that bad when you get a superior product?

Personally I'll continue to use only aterm whether it's included with DSL or not, but I just thought it'd be something to consider.

[tobiaus]

unlike aterm, it's slow, and has no shading.
But the size difference is well worth it.

edit: i always think tc should make a good first impression. no matter how minimal it is, it should be better than any other minimal experience. it's important that tc is tiny, and it's better that it be as tiny as possible, depending on the criteria used to make it tiny. but it amazes me that anyone would say "the change in size is well worth it" when the change in quality is larger than the change in size. (and even the change in size is almost none.)

basically, i would never compare tc to other distributions this way: "it sucks, but the change in size is worth it." that's not what tc is like.

i would say: "tc is incredibly small, but it's also an awesome experience." in many events, the smaller footprint helps to make it awesome (i don't believe that applies to rxvt either, except in rare cases where it should be added to tc and used instead of aterm.)

until now every change in size seems to follow the latter logic, not the former. size is a factor, but quality is important. if there's going to be a change in quality, the decrease in size should be greater than the one in quality. a switch to rxvt (however final) does not fit that. but thank you (very) much for adding qemu, and everything else you've (most often) done to make tc the most excellent distro. it is, but tcb is lessened by this- mostly in quality, slightly in size.

[roberts]

It is not just physical (delivery) size, but about ram (runtime) size. Whereas Tiny Core runs entirely in ram, runtime optimization is an important factor.

With TC's fexlibility you always have the choice to load up aterm as an extension. Just tarball up from prior version into aterm.tce. Or better yet, copy aterm from /usr/bin to /usr/local/bin and then tce it or tcz it.

However, you still have the option to have transparency with the base TC. All three menu choices, Dark, Light, Transparency, remain.

[jpeters]

One thing (apart from the transparency) that I think really puts aterm over rxvt is what I think is a bug in rxvt.  It would not properly read an environment variable exported from .bash_profile unless it was launched as a login shell.  I tested this out to make sure that aterm wasn't being run as login by issuing a command from .bash_profile.  Neither term registered the command, as it should be unless run as a login shell.  However, exporting a variable from .bash_profile should affect all subsequent shells, login or not, but rxvt did not accept it until I exported that variable from one shell and then launched rxvt from the same shell.  Aterm had no trouble reading the variable.

Bash interactive login shell invokes:  (edited)

/etc/profile
~/.bash_profile
~/.bash_login
~/.profile

Non-login interactive shell invokes:

~/.bashrc

[mikshaw]

Yes, that's true.  What I was getting at, though, is that if you export a variable from .bash_profile, it should be available in subshells of that login session.  When you login, .bash_profile is run, then your window manager is run, then you open rxvt.  That's all one line, starting with .bash_profile, so the variable exported from .bash_profile should still be available in rxvt, but is not (or at least was not in DSL...don't know if it's different now in TC).  If you do this in xterm or aterm, it works properly.

[jpeters]

I don't think that's rxvt.....maybe it wasn't set up correctly?  Puppy uses rxvt.  It doesn't have .bash_profile, but if I add an alias to /etc/profile it works both with login and non-login newuser
shells ( 'login user' or 'su - user').   

[mikshaw]

I still don't think you're following what I'm saying, but I'll need to check out the new TC to make sure I'm not wasting everyone's time.
Basically what I had a problem with in rxvt in the pre-aterm DSL was this:
1) Add export VARIABLE=value in .bash_profile (assuming bash is your shell, which in TC would require the addition of the bash extension)
2) logout and then login
3) startx if you've removed the auto-startx
4) run rxvt and echo $VARIABLE
echo $VARIABLE should still return "value", regardless of whether or not rxvt was a login shell, because the variable was exported from the same login shell that spawned the X session and subsequently rxvt.  But my experience said this doesn't work in rxvt.

[jpeters]

again.....you can login or non-login repeatedly into whatever subsidiary shell you want all day,
and echo $variable still works, assuming /etc/profile works like .bash_profile (supposedly, both are read by bash).  I haven't tested the latest RC  release. (puppy is using rxvt v2.6.4)

[^thehatsrule^]

Bash login shell invokes:

/etc/profile
~/.bashrc
~/.bash_profile

Non-login shell invokes:

~/.bashrc

Not exactly - .bashrc is only invoked on interactive non-login shells (see docs for more info).  [ should probably add that what is read depends on several factors ]

Yes, that's true.  What I was getting at, though, is that if you export a variable from .bash_profile, it should be available in subshells of that login session.  When you login, .bash_profile is run, then your window manager is run, then you open rxvt.  That's all one line, starting with .bash_profile, so the variable exported from .bash_profile should still be available in rxvt, but is not (or at least was not in DSL...don't know if it's different now in TC).  If you do this in xterm or aterm, it works properly.

I don't think that using rxvt or any other terminal emulator would affect this, unless it is somehow overriding environmental variables.  I can't seem to reproduce this atm on TC (but it could be due to the differences; using .profile).

I don't think that's rxvt.....maybe it wasn't set up correctly?  Puppy uses rxvt.  It doesn't have .bash_profile, but if I add an alias to /etc/profile it works both with login and non-login newuser
shells ( 'login user' or 'su - user').  

again.....you can login or non-login repeatedly into whatever subsidiary shell you want all day,
and echo $variable still works, assuming /etc/profile works like .bash_profile (supposedly, both are read by bash).  I haven't tested the latest RC  release. (puppy is using rxvt v2.6.4)

The actual shell is different from the terminal emulator.  You would still need to (re)login once for the children to have that set (seems like both those commands you used are for login).

[jpeters]

The actual shell is different from the terminal emulator.  You would still need to (re)login once for the children to have that set (seems like both those commands you used are for login).

You're correct (as usual  )....seems that  'su - usr' is login.  That explains why it was reading /etc/profile.   Although in Puppy  I couldn't get an exported var in /etc/profile NOT to work on all subsequent logins, in TC it only seems to work for the local user; not root or subsidiaries. The new RC worked exactly like the previous terminal. 
 

[^thehatsrule^]

It shouldn't matter which user you log in as - /etc/profile is universal in general for all users.

[jpeters]

It shouldn't matter which user you log in as - /etc/profile is universal in general for all users.

In tc, going into root or an interactive login shell negates the variable set in /etc/profile:

Code: [Select]

tc@box:~$ cd $jp
tc@box:/mnt/hda3/MyFiles$ sudo su - lfs
lfs:~$ pwd
/mnt/hda4/lfs
lfs:~$ cd $jp
lfs:~$ pwd
/mnt/hda4/lfs
lfs:~$ exit
exit
tc@box:/mnt/hda3/MyFiles$ sudo su
root@box:~# cd $jp
root@box:~# pwd
/root
root@box:~# exit
tc@box:/mnt/hda3/MyFiles$


[mikshaw]

Might be related to that recent change in su?  It seemed like it was behaving differently than what I believed was the tradition.  If I remember correctly it changes to root's environment regardless of whether you specify "su -".

In any case, I believe Bash ignores profile if bash_profile exists, so that might have something to do with my  rxvt complaint (if it actually still is a complaint...still haven't checked).