[openbox] I Have Two Instances Of 'autostart.sh Running...

[E R]

Ok on everything that's been mentioned above...

But what about if I don't make compton sleep for one sec on startup it
doesn't create the /tmp/compton.log, but if I let it sleep for a
second it does?


Thanks

On Thu, Oct 23, 2014 at 11:08 PM, Micha <maria.huana at gmx.de> wrote:
> Am 23.10.2014 04:26, schrieb E R:
>>
>> Well I don't claim to be a shell expert, but I never saw this
>> behaviour in previous versions of Openbox...
>>
>> I used the sleep in the past for some things I needed to start at
>> later times, but I don't need this now, and personally never got
>> around to looking into what I had going on at the moment...
>>
>> Thanks for a heads up on eval `cat $HOME/.fehbg` it's always served me
>> well, but if it's overkill then I'm all for doing things in a cleaner
>> fashion.
>>
>> And thanks Dana too....
>>
>> Now I found something else going on in regards to compton. Compton
>> dumps a lot of errors to the console, when I log out of X, so to keep
>> the console clean for things I need to keep an eye on I have compton
>> running the output to a log in /tmp.
>>
>> If I don't make compton sleep for one sec on startup it doesn't create
>> the /tmp/compton.log, but if I let it sleep for a second it does, now
>> this is odd, any thoughts here?
>>
>> And I changed it to sleep 1; (So using a colon after the number is
>> correct?
>
> Yes, that's correct, the semicolon (followed by a space) is used to delimit
> the commands.
>>
>> By the way my background won't load if I only run for feh as;
>> $HOME/.fehbg so I need it instead as sh $HOME/.fehbg
>
> I think, Ralf means ". $HOME/.fehbg", the full-stop at the beginning
> matters...
>>
>> So here's my autostart.sh at the moment...
>>
>>
>> THANKS
>
> But what's with the doubled autostart.sh ?
> With the two subshells, you should have the parent process (autostart.sh)
> and,
> for a short time, two sleeps in your process list, but not 2 autostart.sh.
> With your new version, of course there should occur only 1 sleep.
>
> Micha
>
>>
>>
>> # This shell script is run before Openbox launches.
>> # Environment variables set here are passed to the Openbox session.
>>
>> # D-bus
>> if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS";
>> then
>>         eval `dbus-launch --sh-syntax --exit-with-session`
>> fi
>>
>> # Run XDG autostart things.  By default don't run anything
>> desktop-specific
>> # See xdg-autostart --help more info
>> #DESKTOP_ENV="OPENBOX"
>> #if which /usr/libexec/openbox-xdg-autostart >/dev/null; then
>> #  /usr/libexec/openbox-xdg-autostart $DESKTOP_ENV
>> #fi
>>
>>
>> tint2 &
>> redshift-gtk >/dev/null 2>&1 &
>> (sleep 1; compton --config ~/.config/compton -b --logpath
>> /tmp/compton.log) &
>> /usr/lib64/xfce4/notifyd/xfce4-notifyd &
>> xbindkeys &
>> sh $HOME/.fehbg
>>
>> On Wed, Oct 22, 2014 at 5:45 AM, R. Mattes <rm at mh-freiburg.de> wrote:
>>>
>>> On Wed, 22 Oct 2014 11:27:32 -0400, Dana Jansens wrote
>>>>
>>>> BTW Openbox runs autostart after it has started up now, instead of
>>>> before,
>>>> so those sleeps may be unnecessary with an up-to-date Openbox.
>>>
>>> As I said, my autostart works fine without any sleep invocations. That
>>> strange and silly (sleep ... & ...) seems to
>>> come from the Arch-Wiki page at
>>> https://wiki.archlinux.org/index.php/openbox#autostart. Maybe someone
>>> should
>>> fix that page ;-)
>>>
>>>   Cheers, RalfD
>>>
>>>> On Wed, Oct 22, 2014 at 8:32 AM, R. Mattes <rm at mh-freiburg.de> wrote:
>>>>
>>>>
>>>> On Wed, 22 Oct 2014 01:02:14 -1000, E R wrote
>>>>>>
>>>>>> I don't see anything complicated about this. The way I have the two
>>>>>> sleep lines is a common way of doing this, this method has been
>>>>>> practied this way for many years in Linux...
>>>>>
>>>>> Somehow, some of us here seem to get the impression that you don't
>>>>> really unerstand your own shell program ...
>>>>>
>>>>>> I don't see any behind the keyboard errors here, LMAO, if so, someone
>>>>>> please point it out in that copy of my autostart.sh below...
>>>>>>
>>>>>> # This shell script is run before Openbox launches.
>>>>>> # Environment variables set here are passed to the Openbox session.
>>>>>>
>>>>>> (sleep 1s && tint2) &
>>>>>> (sleep 2s && redshift-gtk >/dev/null 2>&1) &
>>>>>
>>>>> So, here you run two subshells. Each subshell will execute /bin/sleep
>>>>> [1],
>>>>> wait for sleep to exit, an then look at sleeps return code, and, if
>>>>> sleep exited with return value 0, run the next program (tint2 or
>>>>> redshift-gtk). Now, do you really expect 'sleep' to fail??? Most likely
>>>>> not, so you might change this to
>>>>>
>>>>>   (sleep 1s; tint2)&
>>>>>
>>>>> Next question: how long do you expect those subschells to run? The way
>>>>> you programmed this, the shell will terminate once the last program it
>>>>> invoked terminates. So, as long as tint2 or redshift-k run, you'll see
>>>>> to shell processes in your top/ps output. Not what you want - so write
>>>>> it like this:
>>>>>
>>>>>   ( sleep 1s; tint2 & ) &
>>>>>
>>>>> That way the subshell forks tint2 and terminates. No more shell
>>>>> processes arround.
>>>>>
>>>>>> /usr/lib64/xfce4/notifyd/xfce4-notifyd &
>>>>>> /usr/bin/xbindkeys &
>>>>>> eval `cat $HOME/.fehbg`
>>>>>
>>>>> That's a rather baroque way of doing this: a normal .fehbg file
>>>>> contains
>>>>> an invokation of feh like this: feh --bg-fill .... which will terminate
>>>>> feh.
>>>>> So, a simple:
>>>>>
>>>>>   sh $HOME/.fehbg
>>>>>
>>>>> or even_
>>>>>
>>>>>   . $HOME/.fehbg
>>>>>
>>>>> will do.
>>>>> BTW: I never saw the need for all those sleep invokations, in my
>>>>> autostart I'll just run
>>>>>
>>>>> tint2 &
>>>>>
>>>>> et al.
>>>>>
>>>>> HTH Ralf MAttes
>>>>>
>>>>> [1] Actually, it probably won't run an external program but rather
>>>>> invoke the shell's buildin sleep command ....
>>>>>
>>>>> _______________________________________________
>>>>> openbox mailing list
>>>>> openbox at icculus.org
>>>>> http://icculus.org/mailman/listinfo/openbox
>>>>>
>>>
>>>
>>>
>>> --
>>> R. Mattes -
>>> Hochschule fuer Musik Freiburg
>>> rm at mh-freiburg.de
>>>
>>>
>>> _______________________________________________
>>> openbox mailing list
>>> openbox at icculus.org
>>> http://icculus.org/mailman/listinfo/openbox
>>>
>> _______________________________________________
>> openbox mailing list
>> openbox at icculus.org
>> http://icculus.org/mailman/listinfo/openbox
>
>
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox