[the dsc]

My .xinitrc file:

 exec fluxbox &
 fbpid=$!
 
 sleep 3 
 { 
gdeskcal &
kopete &
adept_notifier &
dcop kded kded loadModule knemod &
 } &
 
 wait $fbpid

The bold line was what was supposed to start knemo from the startup, but for some reason it does not, differently from the other ones.

The same command, however, executes it, from the command line or from fbrun.

[i92guboj]

It's just a guess, but dcop depends on a running instance of dcopserver, and maybe on such a early stage it can't initialize for some reason. You can try to add a delay with sleep 10; dcop <whatever>

You can also try to launch dcopserver implicitly from this file. I don't really know. In any case, can you see any error from knemod if you look into the logs?

[the dsc]

The sleep 10 didn't work.

As I'm in an awkward stage of intermediate newbie, I don't knew (and still don't know) where to get any relevant log.

I got knemo working by adding kdeinit to the script, however:

exec fluxbox &

 fbpid=$!

 kdeinit

 sleep 3 
 { 
gdeskcal &
kopete &
adept_notifier &
dcop kded kded loadModule knemod &
 } &
 
 wait $fbpid

[i92guboj]

Nice that you got it working, either way

Originally Posted by the dsc

As I'm in an awkward stage of intermediate newbie, I don't knew (and still don't know) where to get any relevant log.

Since you are using .xinitrc as your config file, I assume you use startx to launch X, don't you?

If that assumption is true, then you can look at the output by just going back to the vt from where you ran startx.

You can just redirect the output to a file. This is the most convenient way, because this way, you can then just open a term on your x session, and use tail to get the logs directly in front of your face.

You could just use "startx > ~/mylogfile.txt" to log the output to that file, but I usually just do it in my xinitrc this way:

My xinitrc:

fvwm &>~/logs/fvwm.log 2>&1

Then, in an xterm, you could do "tail -f ~/logs/fvwm.log" to see the log as it's updated.

[the dsc]

Thanks for the tip. I think I'll make my line somewhat like yours. Just exiting will often add many more message lines and as far as I know, there's no way to scroll back to read what got past the screen.

But I don't understand what is the whole "2>&1" part. (but I just searched for that between the quotation marks in google and there are some answers around)

I thought that just what was before that part would be enough... (even though I thought that something like this would somehow redirect even the graphic output to the text file and end in a blank screen, but apparently I'm wrong )


...
Fluxbox has its own "-log" option, but it logs different things, not the whole "background" stuff.

[i92guboj]

Originally Posted by the dsc

Thanks for the tip. I think I'll make my line somewhat like yours. Just exiting will often add many more message lines and as far as I know, there's no way to scroll back to read what got past the screen.

You don't have to exit, you can do control+atl+f1 to change to vt1, f2 for vt2 and so on. Usually, X is started on vt7, so to go back to X, just use control+alt+f7. You can use then shift+page up/down keys to scroll a bit.

But I don't understand what is the whole "2>&1" part. (but I just searched for that between the quotation marks in google and there are some answers around)

Search for "bash redirection" instead

That line I posted, in fact, has a slight inoffensive error (well, more like it's redundant). It should be

fvwm > ~/logs/fvwm.log 2>&1

In unix/linux, the default streams, stdin, stdout and stderr are referenced using three numbers, respectively: 0, 1 and 2.

So, the > redirects stdout to a file, the 2>&1 part redirects stderr to stdout (which in turn is redirected to a file). This way, both stderr and stdout will be logged to a file.

This is the way that sh does it, so, it's *the way* to do it if you are going to use this config on shells other than bash.

Bash also accepts this form:

fvwm &> ~/logs/fvwm.log

This redirects both (stderr and stdout) to a file. That's why I said above that the first line I posted has a small typo on it which made it redundant.

I thought that just what was before that part would be enough...

Yep, it was a typo, as I explain above.

(even though I thought that something like this would somehow redirect even the graphic output to the text file and end in a blank screen, but apparently I'm wrong )

The graphic stuff is not in shell land. It's done via a framebuffer or via an accelerated graphics driver which operates in a completely different way, so it can't be saved this way.