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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ottavio Caruso <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <uaagkm$3k760$[email protected]>,
Ottavio Caruso <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ottavio Caruso <[email protected]> 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) [email protected]
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 02/08/2023 um 10:11 schrieb Keith Thompson:

Ottavio Caruso <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-08-01, Ottavio Caruso <[email protected]> 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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Jim Jackson <[email protected]> wrote:

On 2023-08-01, Ottavio Caruso <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 01 Aug 2023 04:44:04 -0400, Ottavio Caruso <[email protected]> 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/[email protected]e/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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-08-02, Kenny McCormack <[email protected]> wrote:

In article <[email protected]>,
Jim Jackson <[email protected]> wrote:

On 2023-08-01, Ottavio Caruso <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ottavio Caruso <[email protected]> writes:

Am 02/08/2023 um 10:11 schrieb Keith Thompson:

Ottavio Caruso <[email protected]> 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) [email protected]
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-08-02, Kenny McCormack <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Jim Jackson <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-08-03, Kenny McCormack <[email protected]> wrote:

In article <[email protected]>,
Jim Jackson <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)