v3 changes
Thanks folks for keeping fvwm alive. I didn't find a reason to switch from 2.6.8 until now (it doesn't compile on Devuan 4 any more). About some immediately visible changes: * No problem with output going into a separate logfile. Destination could be sett-able on the command line instead of the environment. * Love the asciidoc documentation sources. The old change in documentation format back in the old days was part of the reason I didn't work on fvwm any more. * FvwmCpp is gone. Okay, can be easily replaced by scripting. No hard feelings. * No more errors with plain "-Wall -Werror". Good. * INSTALL file is gone. Bad. Required by GNU standards. * Third party (Go) sources in distribution = license trouble. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Where's stdout + stderr
On Sat, Nov 13, 2021 at 05:33:15PM -0700, Jaimos Skriletz wrote: > On Sat, Nov 13, 2021 at 5:25 PM Dominik Vogt wrote: > > > > The Devuan upgrade finally forces me to switch to v3, but it's > > giving me a _hard_ time debugging the configuration during the > > transition. There is zero indication of what fvwm is doing in the > > console output. Where's the error output? > > > > Checkout the -v option in the manual page. Fvwm now outputs logs to > ~/.fvwm/fvwm3-output.log and needs to be turned on. You can turn it on > for a running process using the SIGUSR2 signal. Thanks. This "3" stuff really needs to go away. Feels like being back to the nineties. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Where's stdout + stderr
On Sat, Nov 13, 2021 at 5:25 PM Dominik Vogt wrote: > > The Devuan upgrade finally forces me to switch to v3, but it's > giving me a _hard_ time debugging the configuration during the > transition. There is zero indication of what fvwm is doing in the > console output. Where's the error output? > Checkout the -v option in the manual page. Fvwm now outputs logs to ~/.fvwm/fvwm3-output.log and needs to be turned on. You can turn it on for a running process using the SIGUSR2 signal. jaimos
FVWM: Where's stdout + stderr
The Devuan upgrade finally forces me to switch to v3, but it's giving me a _hard_ time debugging the configuration during the transition. There is zero indication of what fvwm is doing in the console output. Where's the error output? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: a problem of .login starting fvwm (migration suse-ubuntu)
On Sun, 14 Nov 2021, Cameron Simpson wrote: On 14Sep2021 15:36, Lucio Chiappetti wrote: I am migrating (actually, configuring a new PC) from opensuse 42.3 to xubuntu 20.04.3. Thanks for your interest. In the meanhile I arranged an acceptable workaround. Apparently ALL of the .login is not executed This is pretty normal. The display manager is running fvwm as your "session", so it starts it directly without using a shell at all. My long standing approach has been to have a .xsession file specifying my desktop session. I'm not sure whether that's compatible with the default xubuntu way. To recap, a "text terminal then startx" style login goes: Used that only once for a laptop which failed to start X at boot (or perhaps back in the old times of Sun workstation in the '90s ...) An XDM (et al) style login goes: (not just the part relevant to XSESSION_IS_UP ...by the way what is the correct way in ubuntu to check I am in an X session ?) Apparently in xubuntu the things to be tested are if ( $?XDG_SESSION_TYPE != 0 ) then if ($XDG_SESSION_TYPE == x11) then my arrangement has been to move some conditional code in .cshrc, and leave some conditional X server stuff (like the X11 bell emulation) in .login, and force its execution in fvwm with a xterm -ls in StartFunction Thanks anyhow -- 'It seemed to me,' said Wonko the Sane, 'that any civilization that had so far lost its head as to need to include a set of detailed instructions for use in a package of toothpicks, was no longer a civilization in which I could live and stay sane.' Douglas Adams, So Long, and Thanks for All the Fish
Re: FVWM: a problem of .login starting fvwm (migration suse-ubuntu)
On 14Sep2021 15:36, Lucio Chiappetti wrote: >I am migrating (actually, configuring a new PC) from opensuse 42.3 to >xubuntu 20.04.3. In particular I would like to clone my fvwm >configuration (since I have a screen of the same size), the one in >http://sax.iasf-milano.inaf.it/~lucio/WWW/Opinions/window.html > >What I am noticing (which is probably not directly related fvwm itself >but to the way it is started with the X server) is that the fvwm >session does not run my .login (I am since ages a tcsh user, so I have >a .cshrc and a .login).Such .login is executed correctly in a ssh >session. > >The .login has few items (a PATH setting, a font path xset +fp setting >(plus other audio stuff so far commented out) which is conditional to >a $?XSESSION_IS_UP, and a setenv of some locale like LC_TIME to >en_US.UTF-8) > >Apparently ALL of the .login is not executed This is pretty normal. The display manager is running fvwm as your "session", so it starts it directly without using a shell at all. This is generally safer because many shell startups have some tty interaction which doesn't make sense in a batch environment (the headless process of running fvwm in a GUI directly). My long standing approach has been to have a .xsession file specifying my desktop session. Mine is this: #!/bin/sh . /etc/profile . $HOME/.profile exec $HOME/rc/x11/session To make your startup easier you'd want a tcsh based script, something like: #!/usr/bin/tcsh source /etc/login source $HOME/.login exec fvwm (Untested, and I am not a csh user so the syntax may be a bit incorrect.) In my setups I have environment setting in .profile and interactive stuff in .zshrc (or .bashrc, or .cshrc for you as a tcsh user). So the session script sources the .login (environment setting) but _not_ the .cshrc (interactive things). To recap, a "text terminal then startx" style login goes: - login tcsh - start x11, your environment is already set up An XDM (et al) style login goes: - X11 active - run .xsession - - source .login etc - - execute fvwm as the session, so that the logout happens when fvwm logs out Just a different ordering. >(not just the part relevant to XSESSION_IS_UP ...by the way what is >the correct way in ubuntu to check I am in an X session ?) I check that $DISPLAY is not empty, and maybe do an: xdpyinfo >&/dev/null as an additional check. In Bounre shell that might be like this: if [ -n "$DISPLAY" ] && xdpyinfo >/dev/null 2>&1 then ... x11 stuff here ... fi You'll have to adjust for csh. Cheers, Cameron Simpson
