I have a few scripts which refuse to do anything if I put the shebang on
the first line, example:

#!/bin/sh
redshift -P -O 3200

(sh is aliased to dash)

This works if launched from the command line, but not if run as a
startup script any time I log in the GUI (Mate on Debian).

It works either way if I remove the shebang. And this is for most custom
scripts that I add to mate-session-properties:
https://manpages.debian.org/testing/mate-session-manager/mate-session-properties.1.en.html

What's going on in here?

--
Ottavio Caruso

Am 01/08/2023 um 08:44 schrieb Ottavio Caruso:
> I have a few scripts which refuse to do anything if I put the shebang on
> the first line, example:
>
> #!/bin/sh
> redshift -P -O 3200
>
> (sh is aliased to dash)
>
> This works if launched from the command line, but not if run as a
> startup script any time I log in the GUI (Mate on Debian).
>
> It works either way if I remove the shebang. And this is for most custom
> scripts that I add to mate-session-properties:
> https://manpages.debian.org/testing/mate-session-manager/mate-session-properties.1.en.html
>
> What's going on in here?
>
>
>

Anybody? Please!

--
Ottavio Caruso

In article <uaagkm$3k760$1@dont-email.me>,
Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:
>I have a few scripts which refuse to do anything if I put the shebang on
>the first line, example:
>
>#!/bin/sh
>redshift -P -O 3200
>
>(sh is aliased to dash)
>
>This works if launched from the command line, but not if run as a
>startup script any time I log in the GUI (Mate on Debian).
>
>It works either way if I remove the shebang. And this is for most custom
>scripts that I add to mate-session-properties:

I suppose the obvious question is: Why do you care? If it (whatever "it"
is) works w/o the shebang, why do you pursue making it work with it?

Note that your followup makes this sound pretty urgent, but it sounds
pretty academic to me.

--
The motto of the GOP "base": You can't *be* a billionaire, but at least you
can vote like one.

Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:

> Am 01/08/2023 um 08:44 schrieb Ottavio Caruso:
>> I have a few scripts which refuse to do anything if I put the shebang
>> on the first line, example: #!/bin/sh redshift -P -O 3200

Calling it this way the shell searches for the redshift program in its
PATH environment variable. Now the environment of the GUI could be
different from your environment, from which you start it interactively.
Have you tried calling the redshift program with its full path instead?

>> (sh is aliased to dash) This works if launched from the command line,
>> but not if run as a startup script any time I log in the GUI (Mate on
>> Debian). It works either way if I remove the shebang. And this is
>> for most custom scripts that I add to mate-session-properties:
>> https://manpages.debian.org/testing/mate-session-manager/mate-session-properties.1.en.html
>> What's going on in here?

One possibility to find out these things is writing output lines in your
startup script, like:

echo "Startup: PATH=$PATH"

Or to find out the running shell you could try:

echo "Startup: Processes which match shell PID" ps | grep $$

I don't know where output from your startup script is written to, so if
you're not sure you can redirect it to a file, e.g.

echo "PATH=$PATH" >/tmp/startup.out

HTH

Joerg

Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:
> I have a few scripts which refuse to do anything if I put the shebang
> on the first line, example:
>
> #!/bin/sh
> redshift -P -O 3200
>
> (sh is aliased to dash)
>
> This works if launched from the command line, but not if run as a
> startup script any time I log in the GUI (Mate on Debian).
>
> It works either way if I remove the shebang. And this is for most
> custom scripts that I add to mate-session-properties:
> https://manpages.debian.org/testing/mate-session-manager/mate-session-properties.1.en.html
>
> What's going on in here?

How exactly does it not work? Does it just do nothing, with no error
message?

Have you set execute permission (chmod +x) on the script file?

Try adding some debugging statements to your script, for example:

#!/bin/sh
echo "$0 invoking redshift at $(date)" >> $HOME/redshift.log
echo "PATH=$PATH" >> $HOME/redshift.log
type redshift >> $HOME/redshift.log 2>&1
redshift -P -O 3200
echo "After redshift, status=$?" >> $HOME/redshift.log

Does it create $HOME/redshift.log ?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Am 02/08/2023 um 10:11 schrieb Keith Thompson:
> Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:
>> I have a few scripts which refuse to do anything if I put the shebang
>> on the first line, example:
>>
>> #!/bin/sh
>> redshift -P -O 3200
>>
>> (sh is aliased to dash)
>>
>> This works if launched from the command line, but not if run as a
>> startup script any time I log in the GUI (Mate on Debian).
>>
>> It works either way if I remove the shebang. And this is for most
>> custom scripts that I add to mate-session-properties:
>> https://manpages.debian.org/testing/mate-session-manager/mate-session-properties.1.en.html
>>
>> What's going on in here?
>
> How exactly does it not work? Does it just do nothing, with no error
> message?
>
> Have you set execute permission (chmod +x) on the script file?
>
> Try adding some debugging statements to your script, for example:
>
> #!/bin/sh
> echo "$0 invoking redshift at $(date)" >> $HOME/redshift.log
> echo "PATH=$PATH" >> $HOME/redshift.log
> type redshift >> $HOME/redshift.log 2>&1
> redshift -P -O 3200
> echo "After redshift, status=$?" >> $HOME/redshift.log
>
> Does it create $HOME/redshift.log ?
>

Yes (launched from logging out and logging in Mate):

$ cat redshift.log
/home/oc/opt/bin/redshift invoking redshift at Wed 2 Aug 14:17:16 BST 2023
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin
redshift is /usr/bin/redshift
After redshift, status=0

--
Ottavio Caruso

On 2023-08-01, Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:
> I have a few scripts which refuse to do anything if I put the shebang on
> the first line, example:
>
> #!/bin/sh
> redshift -P -O 3200
>
> (sh is aliased to dash)
>
> This works if launched from the command line, but not if run as a
> startup script any time I log in the GUI (Mate on Debian).

use the full path name to the executable e.g.

/home/me/bin/redshift ...etc

redshift is probably not in one of the directories listed in the PATH
variable.
>
> It works either way if I remove the shebang. And this is for most custom
> scripts that I add to mate-session-properties:
> https://manpages.debian.org/testing/mate-session-manager/mate-session-properties.1.en.html
>
> What's going on in here?
>
>
>

In article <slrnuckpcj.3ci.jj@iridium.wf32df>,
Jim Jackson <jj@franjam.org.uk> wrote:
>On 2023-08-01, Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:
>> I have a few scripts which refuse to do anything if I put the shebang on
>> the first line, example:
>>
>> #!/bin/sh
>> redshift -P -O 3200
>>
>> (sh is aliased to dash)
>>
>> This works if launched from the command line, but not if run as a
>> startup script any time I log in the GUI (Mate on Debian).
>
>use the full path name to the executable e.g.
>
> /home/me/bin/redshift ...etc
>
>redshift is probably not in one of the directories listed in the PATH
>variable.

Your response makes no sense, given the complete history of OP's posts on
this thread.

BTW, I absolutely hate the "Use full paths" mantra as the solution to all
problems. It is a band-aid at best.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/DanQuayle

On Tue, 01 Aug 2023 04:44:04 -0400, Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:

> I have a few scripts which refuse to do anything if I put the shebang on
> the first line, example:
>
> #!/bin/sh
> redshift -P -O 3200
>
> (sh is aliased to dash)
>
> This works if launched from the command line, but not if run as a
> startup script any time I log in the GUI (Mate on Debian).
>
> It works either way if I remove the shebang. And this is for most custom
> scripts that I add to mate-session-properties:
> https://manpages.debian.org/testing/mate-session-manager/mate-session-properties.1.en.html
>
> What's going on in here?

How is the script being invoked?

In the case of redshift, which I use, it fails if the gui is not running
already. As I prefer using run level 3, I've set up a script to start it.
The script is started after login by systemd.

$ cat /etc/xdg/systemd/user/redshift-gtk.service
[Unit]
Description=Redshift display colour temperature adjustment (GUI)
Documentation=http://jonls.dk/redshift/
After=display-manager.service
Conflicts=redshift.service

[Service]
ExecStart=/usr/local/bin/redshift-gtk
Restart=always
RestartSec=15

[Install]
WantedBy=default.target

That way it works no matter which desktop environment I start, and I don't
run into problems with more than one copy trying to start.

$ systemctl --user status redshift-gtk.service
● redshift-gtk.service - Redshift display colour temperature adjustment (GUI)
Loaded: loaded (/etc/xdg/systemd/user/redshift-gtk.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2023-07-30 12:04:31 EDT; 3 days ago
Docs: http://jonls.dk/redshift/
Main PID: 6667 (redshift-gtk)
Tasks: 5 (limit: 19118)
Memory: 19.2M
CPU: 20.721s
CGroup: /user.slice/user-500.slice/user@500.service/redshift-gtk.service
├─6667 /bin/bash /usr/local/bin/redshift-gtk
├─6684 /usr/bin/python3 /usr/bin/redshift-gtk
└─6685 /usr/bin/redshift -v

$ cat /usr/local/bin/redshift-gtk
#!/bin/bash
/usr/bin/sleep 20
/usr/bin/redshift-gtk

The sleep 20 gives me enough time to enter my ssh pass phrase and the startx
command.

Even with using systemd and the auto restart, it will fail if I take too long
as systemd will stop trying after too many failed attempts. If that happens, I
just manually run "systemctl --user start redshift-gtk.service".

Regards, Dave Hodgins

On 2023-08-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <slrnuckpcj.3ci.jj@iridium.wf32df>,
> Jim Jackson <jj@franjam.org.uk> wrote:
>>On 2023-08-01, Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:
>>> I have a few scripts which refuse to do anything if I put the shebang on
>>> the first line, example:
>>>
>>> #!/bin/sh
>>> redshift -P -O 3200
>>>
>>> (sh is aliased to dash)
>>>
>>> This works if launched from the command line, but not if run as a
>>> startup script any time I log in the GUI (Mate on Debian).
>>
>>use the full path name to the executable e.g.
>>
>> /home/me/bin/redshift ...etc
>>
>>redshift is probably not in one of the directories listed in the PATH
>>variable.
>
> Your response makes no sense, given the complete history of OP's posts on
> this thread.
>
> BTW, I absolutely hate the "Use full paths" mantra as the solution to all
> problems. It is a band-aid at best.

Is it?

I agree for system utilities - get the default PATH right. But for
executables in users home space or in non-usual-system places, then I
believe the advice is valid.

Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:
> Am 02/08/2023 um 10:11 schrieb Keith Thompson:
>> Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:
>>> I have a few scripts which refuse to do anything if I put the shebang
>>> on the first line, example:
>>>
>>> #!/bin/sh
>>> redshift -P -O 3200
>>>
>>> (sh is aliased to dash)
>>>
>>> This works if launched from the command line, but not if run as a
>>> startup script any time I log in the GUI (Mate on Debian).
>>>
>>> It works either way if I remove the shebang. And this is for most
>>> custom scripts that I add to mate-session-properties:
>>> https://manpages.debian.org/testing/mate-session-manager/mate-session-properties.1.en.html
>>>
>>> What's going on in here?
>> How exactly does it not work? Does it just do nothing, with no
>> error message?

You didn't answer that.

>> Have you set execute permission (chmod +x) on the script file?

You didn't answer that either.

>> Try adding some debugging statements to your script, for example:
>> #!/bin/sh
>> echo "$0 invoking redshift at $(date)" >> $HOME/redshift.log
>> echo "PATH=$PATH" >> $HOME/redshift.log
>> type redshift >> $HOME/redshift.log 2>&1
>> redshift -P -O 3200
>> echo "After redshift, status=$?" >> $HOME/redshift.log
>> Does it create $HOME/redshift.log ?
>>
>
> Yes (launched from logging out and logging in Mate):
>
> $ cat redshift.log
> /home/oc/opt/bin/redshift invoking redshift at Wed 2 Aug 14:17:16 BST 2023
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin
> redshift is /usr/bin/redshift
> After redshift, status=0

That indicates that the redshift command is being invoked and completes
successfully. So what's the problem?

You said the script behaves differently when invoked from the command
line vs. being invoked on startup, but you've only shown us the log from
a single invocation, and you haven't told us how you invoked it.

Apparently your script is named "/home/oc/opt/bin/redshift".
If /home/oc/opt/bin is in your $PATH before /usr/bin, then the
script will invoke itself recursively, and will likely die when
it runs out of memory. We don't have enough information to know
whether that's the problem, but I suggest giving your script a
different name, perhaps "redshift-wrapper".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

In article <slrnucl8bp.3ci.jj@iridium.wf32df>,
Jim Jackson <jj@franjam.org.uk> wrote:
....
>I agree for system utilities - get the default PATH right. But for
>executables in users home space or in non-usual-system places, then I
>believe the advice is valid.

I know you do.

--
I've been watching cat videos on YouTube. More content and closer to
the truth than anything on Fox.

On 2023-08-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> BTW, I absolutely hate the "Use full paths" mantra as the solution to all
> problems. It is a band-aid at best.

So, like, I guess you're not using containers like all the other
children.

/me ducks under table.

On 2023-08-03, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <slrnucl8bp.3ci.jj@iridium.wf32df>,
> Jim Jackson <jj@franjam.org.uk> wrote:
> ...
>>I agree for system utilities - get the default PATH right. But for
>>executables in users home space or in non-usual-system places, then I
>>believe the advice is valid.
>
> I know you do.

Sigh. Ok I should have explicitly asked, but I'd actually appreciate
your view on the problem with that advice.