.xsession and .profile

[mikshaw]

I assumed the .xsession file was pretty much the same as .xinitrc in many other distros, but for some reason some commands don't work.
I'm trying to add X fonts using xset +fp /path/to/fonts and to modify my keys with xmodmap, but neither seem to work unless I run the commands manually after the desktop loads.   I've tried reorder ing the commands and even adding a pause so Xvesa can load before running the commands, but they just don't work.  I added a command in the same area to run wbar, and that works fine, so I know the file is running.  I get no output to read, maybe due to the redirect to /dev/null in startx.

Current .xsession:

Code: [Select]

Xvesa -br -mouse /dev/psaux,5 -screen 1024x768x32 -shadow -nolisten tcp -I 2>&1 > $HOME/X.log &

#while [ ! -e /tmp/.X11-unix/X0 ]; do false; done
until pidof Xvesa; do false; done
#f=$HOME/.fonts
#xset b off +fp $f/artwiz,$f/lfp-fix,$f/proggy,$f/sgi,$f/terminus
xset +fp $HOME/.fonts/terminus
xmodmap $HOME/.Xmodmap
wbar &

exec jwm 2>&1 > $HOME/windowmanager.logThe commented lines are variations of the uncommented lines.

============

Also noticed my aliases in .profile don't seem to be working, but this may be an issue with a flaky remaster.

[^thehatsrule^]

Afaik you need to background those (by appending & to every command)

---

You're talking about how they don't show up while in a X terminal emulator?

.profile is typically reserved for login shells only.  If you want to use your existing .profile each time, you can change your terminal emulator to always call a login shell, ie for aterm, change the invocation to `aterm -e sh --login`

The ash shell part of BusyBox does not have a dedicated interactive nonlogin startup source file.  If you prefer to use another file, you can set ENV to a file of your choice.

(edit: corrected to interactive)

[mikshaw]

Again it seems to be my own dumb fault.  I booted a clean tinycore.gz (still with the added extensions), and those commands worked as expected from .xsession, so I must have broken something in my remaster.  Backgrounding is not necesary for xset, since it closes itself after it does its business.

On the subject of .profile, if what you say is true I don't understand why  there would already be aliases set in .profile in a default tinycore system.  I didn't think to check if my remaster caused that trouble, but I assume it was...I'll check again later.

I'm thinking of setting my shell to bash, since I already have it installed, and I'm much more comfortable with it than with other shells, but I think I need to reconsider how much I really need to do with a remaster.  I could just stick with adding reiserfs and do everything else from within my $HOME files as I did with DSL.

[^thehatsrule^]

Did some testing, results may not be the same as others:
- using xset, etc. commands to the default .xsession works
- if using redirection on jwm, the extra commands only work with backgrounding
Seems a bit odd, but I wouldn't know how to explain it

I think those aliases were just defaults.  It'd be used on a VT, or ssh session, etc.

It would probably be better to use bash only as your interactive shell, and leave the rest for ash to handle because it's faster and lighter.

[mikshaw]

if using redirection on jwm, the extra commands only work with backgrounding

I got dwm installed on tinycore , so I'll probably be using that now.
Side note: the latest version of dwm (5.3.1) doesn't build on Tinycore with the current extensions due to some addition that isn't supported by the Xorg headers (usegrab), but 5.2 works fine.

I think those aliases were just defaults.  It'd be used on a VT, or ssh session, etc.

I think your right.  My alias was mc='mc -b'.  When I was in the console, I seem to remember it wasn't that ugly blue it is when not using -b.  On the subject of mc, it told me in Tinycore console that I wasn't in a linux console or xterm, so the panels didn't toggle.  I seem to remember seeing this in DSL too, but for now I can't remember what I did to fix it.  Might require achange to inittab, but I'm planning to make some changes to that file anyway.

[hjkl]

Hi mikshaw,
OT:
I also use dwm as my window manager.  I just compiled dwm(5.3.1) on TinyCore.

e8120aa61e855b59ec642dfef767e19f  tinycore_1.0rc3.iso
0e718639040e05ca7a3822f1a7d1163e  compiletc.tce
 tc@box[~]$ tce-load compiletc.tce

776970757181e3beb82a77054e2ded76  Xorg-7.4-dev-light.tce
 tc@box[~]$ tce-load Xorg-7.4-dev-light.tce

65b6eaa997984685887450885f5a36c6  dwm-5.3.1.tar.gz
 tc@box[~]$ tar -xvzf dwm-5.3.1.tar.gz
 tc@box[~]$ cd dwm-5.3.1
 tc@box[~/dwm-5.3.1]$ make

Enjoy!!

[mikshaw]

Thanks for pointing me to Xorg-7.4-dev-light.  I'll definitely try that. 

OT:
I don't understand how a _smaller_ version of the same package would fix a problem with a missing function, but it's worth a try.   I thought the addition of usegrab in the latest dwm was the whole problem, but if you were able to build it using essentially the same headers, I'm guessing the blame is likely to be user error.  If you didn't need to modify  config.mk, I'm guessing dev-light might install into /usr/X11R6, which could be a significant difference.
The thing about staying updated with dwm is that it seems to be becoming less important to do so.  It's been consistantly stable since the developer stopped playing with whims near the beginning, and the last few updates seem to contain changes that have made little impact on me.  I'm guessing it will soon become "done", or as close to done as an open source project can be.  Either that or it's in danger of becoming something else, possibly suffering from whims once again.

EDIT:  ahhh....user error...again!  I think my brain has been leaking out my ears lately.  Instead of creating a new custom config.h using the latest config.def.h file as a base, I copied the one I had used for 5.2.  It turns out that usegrab is a new variable added to the dwm 5.3.1 config, and has nothing to do with Xlib =o)

[^thehatsrule^]

The .info has some ... info:

Due to popular demand, now offering a headers-only version. By using this compiling might be easier, but you will also lack the advanced functionality.

Some of us had been requesting this because there were sometimes problems in using the full package due to it including more features, but usually had linking problems, etc.  If you do want the features, you could manually add to/fix the build commands, at least for now.

[mikshaw]

Some answers....

The aliases were indeed not being used in aterm because .rofile isn't being read by a non-login shell.  I'm not sure how ash handles these shells, but when I changed my default shell to Bash and used my usual .bashrc and .bash_profile files, the aliases work.  It also fixed subshells in midnight commander.

Some of my other troubles seem to have been caused by a bad remaster.  I think when I first extracted tinycore.gz I used cpio -i without the other options listed in the wiki.  The last remaster I did works well (mostly).

There are still a couple of weird things happening, but I'm sure I'll find the problems soon enough...
The xmodmap command in .xsession doesn't seem to work if I exit to prompt and then use "startx" to return to the desktop...this seems bizarre to me at the moment, but it might be yet another thing I'm overlooking.
If I'm in aterm and use "sudo su", root retains my  environment.  There is no visual clue that I'm root.  If I use "sudo su -", I'm logged in a second time as tc. Ctrl+d logs out that new instance and I'm back to the original prompt.  I assumed "sudo su -" would start a root session with root's environment.  I have a workaround of sorts, a "sudo aterm"  command, and changing the prompt in .bashrc if $USER is root.

The ash shell part of BusyBox does not have a dedicated interactive startup source file.  If you prefer to use another file, you can set ENV to a file of your choice.

I overlooked this earlier.  Not knowing this is likely  the root of some of my confusion.

[^thehatsrule^]

It could be something you've changed (again).  For me, using `sudo su ` shows the regular root@hostname:/current/path#
Maybe you'll need to add something for bash, like root's .bashrc ?

It is expected that using `sudo su - ` shows a regular tc user shell, due to how TC starts up: by autologging in as root first (see /etc/inittab), then changes the user to tc (see /root/.profile).  I'm not sure whether or not some other startup scripts depend on this setup though... wonder if it can be changed.

[mikshaw]

Maybe you'll need to add something for bash, like root's .bashrc ?

I tried that, and got the same result.  After changing my shell to Bash, using "sudo su" in a terminal gives root the Bash shell as well, as you apparently guessed.  Maybe i'll need to give root a new PS1 from root's bash_profile.  In any case, the current setup I have gives root my environment, but I set root's PS1 from my .bashrc (if [ "$USER" == "root" ]), so it's a useable workaround.

Overall I'm mostly pleased with the results of today's work.  I'm almost as comfortable with TC as I am with DSL.  The potential TC has is much more flexible tha DSL, considering its very easy to install apps to /usr/local and everything is in standard directories.  On top of that, my persistent /usr/local means lower ram usage.

[mikshaw]

Back to .xsession  (I took a break from TC until 1.1 was final)
I understand startx runs .xsession directly in order to remove a dependancy on xinit.  This means that Xvesa is also run directly, and backgrounded so that we can run xmodmap and xset and whatever else.  Maybe that backgrounding has something to do with my commands not being reliable, I don't know, but what I do know is that this setup leaves X running after all other applications close (including the window manager, if it's closed with its native quit function).  What I'm wondering is what does jwm, or more likely exittc, do when jwm is closed which also safely takes out X with it?  Is it simply killing the Xvesa process after jwm closes?
I'm guessing I can use wait $pid-of-dwm and then explicitly close Xvesa in .xsession.  Is that a sensible behavior?  Sounds like it should work, but I haven't tried it yet.
Also guessing Xorg extension includes xinit and a different startx script, so if I download that I'd end up with the behavior I'm accustomed to in other distros?

[curaga]

The Xorg extension does not include xinit and it's own startx precisely not to mess with the script in the base

[mikshaw]

Okay, that's good to know.
So I'll try  te wait command in .xsession and see how that goes.
Still struggling with the other commands in .xsession...my keyboard-driven window manager relies on xmodmap in order to anything useful (it's configured to use both windows keys independently so as not to interfere with application hotkeys), and xset is wanted for aesthetic reasons (X fonts and wallpaper).  I have a feeling there is still something I broke, most likely something i'm overlooking in a /home/tc config file.

Also thinking seriously about using Bash only for interactive shells, as ^thehatsrule^ suggested.  I suppose that could be easily done by  changing aterm to use Bash automatically, and for all I know might also fix my issue with mc taking forever to start in tty.

Thanks again.

[roberts]

Yes. In exittc, I am killing the Xserver.