Find the answer to your Linux question:
Results 1 to 6 of 6
My .xinitrc file: Code: exec fluxbox & fbpid=$! sleep 3 { gdeskcal & kopete & adept_notifier & dcop kded kded loadModule knemod & } & wait $fbpid The bold line ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Newbie
    Join Date
    Apr 2007
    Posts
    214

    How to start knemo from .xinitrc on fluxbox?


    My .xinitrc file:


    Code:
     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.

  2. #2
    Linux Guru
    Join Date
    Nov 2007
    Location
    Córdoba (Spain)
    Posts
    1,513
    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?

  3. #3
    Linux Newbie
    Join Date
    Apr 2007
    Posts
    214
    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:

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

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru
    Join Date
    Nov 2007
    Location
    Córdoba (Spain)
    Posts
    1,513
    Nice that you got it working, either way

    Quote Originally Posted by the dsc View Post
    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.

  6. #5
    Linux Newbie
    Join Date
    Apr 2007
    Posts
    214
    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.

  7. #6
    Linux Guru
    Join Date
    Nov 2007
    Location
    Córdoba (Spain)
    Posts
    1,513
    Quote Originally Posted by the dsc View Post
    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

    Code:
    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:

    Code:
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •