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?
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?
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 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 <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 ?
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?
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.
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?
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.
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 shebangHow exactly does it not work? Does it just do nothing, with no
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?
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
BTW, I absolutely hate the "Use full paths" mantra as the solution to all problems. It is a band-aid at best.
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 297 |
Nodes: | 16 (2 / 14) |
Uptime: | 22:11:13 |
Calls: | 6,667 |
Calls today: | 1 |
Files: | 12,216 |
Messages: | 5,337,347 |