info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
(Linux) cron job shell?
21 views
Skip to first unread message
Kenny McCormack
Aug 2, 2017, 8:01:48 AM8/2/17
to
It is well known that cron jobs (as listed in your crontab file) run with a
very limited environment and that you have to end up specifying a lot of
things that ordinarily (I.e., when run from the usual interactive command
line) "just work". It is also well known that the command line itself
(I.e., the actual text listed in the crontab file) can be problematic; it
may not work as expected, due to two factors:
1) It may be scanned with a different (generally, more primitive) shell
than that which the user is used to (i.e., an old 'sh' variant - or
maybe a "POSIX" mode shell - rather than bash)
2) The "%" character is special in crontab. There may be other "magic"
characters as well.
That all said, I found something today that I find puzzling. I have
something like the following in a crontab line:
. someFile;~/bin/someProgram
Now, this fails, with message "someFile not found". If I change it to:
. ./someFile;~/bin/someProgram
It works. What is interesting here is that, according to "man bash", the
current directory is not searched (for the "." command) if the shell is in
POSIX mode. This, then, would account for the need for the "./". But if
that was the case, then you'd expect the "~" thing to fail, since ~
expansion isn't POSIX.
So, why does is it OK with the ~ expansion, but not with finding someFile
in the current directory (w/o using "./") ?
--
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/ThePublicGood
very limited environment and that you have to end up specifying a lot of
things that ordinarily (I.e., when run from the usual interactive command
line) "just work". It is also well known that the command line itself
(I.e., the actual text listed in the crontab file) can be problematic; it
may not work as expected, due to two factors:
1) It may be scanned with a different (generally, more primitive) shell
than that which the user is used to (i.e., an old 'sh' variant - or
maybe a "POSIX" mode shell - rather than bash)
2) The "%" character is special in crontab. There may be other "magic"
characters as well.
That all said, I found something today that I find puzzling. I have
something like the following in a crontab line:
. someFile;~/bin/someProgram
Now, this fails, with message "someFile not found". If I change it to:
. ./someFile;~/bin/someProgram
It works. What is interesting here is that, according to "man bash", the
current directory is not searched (for the "." command) if the shell is in
POSIX mode. This, then, would account for the need for the "./". But if
that was the case, then you'd expect the "~" thing to fail, since ~
expansion isn't POSIX.
So, why does is it OK with the ~ expansion, but not with finding someFile
in the current directory (w/o using "./") ?
--
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/ThePublicGood
Kaz Kylheku
Aug 2, 2017, 8:26:54 AM8/2/17
to
On 2017-08-02, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> It works. What is interesting here is that, according to "man bash", the
> current directory is not searched (for the "." command) if the shell is in
> POSIX mode. This, then, would account for the need for the "./". But if
> that was the case, then you'd expect the "~" thing to fail, since ~
> expansion isn't POSIX.
"Tilde expansion" is POSIX.
> It works. What is interesting here is that, according to "man bash", the
> current directory is not searched (for the "." command) if the shell is in
> POSIX mode. This, then, would account for the need for the "./". But if
> that was the case, then you'd expect the "~" thing to fail, since ~
> expansion isn't POSIX.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01
Kenny McCormack
Aug 2, 2017, 8:43:30 AM8/2/17
to
In article <201708020...@kylheku.com>,
OK, so you are asserting that the shell that parses the command line is,
indeed, bash-in-posix-mode. Right?
--
So to cure the problem of arrogant incompetent rich people we should turn
the government over to an arrogant incompetent trust fund billionaire
who knows nothing about government and who has never held a job in his
entire spoiled life?
indeed, bash-in-posix-mode. Right?
--
So to cure the problem of arrogant incompetent rich people we should turn
the government over to an arrogant incompetent trust fund billionaire
who knows nothing about government and who has never held a job in his
entire spoiled life?
Janis Papanagnou
Aug 2, 2017, 9:13:35 AM8/2/17
to
On 02.08.2017 14:01, Kenny McCormack wrote:
> It is well known that cron jobs (as listed in your crontab file) run with a
> very limited environment and that you have to end up specifying a lot of
> things that ordinarily (I.e., when run from the usual interactive command
> line) "just work". It is also well known that the command line itself
> (I.e., the actual text listed in the crontab file) can be problematic; it
> may not work as expected, due to two factors:
> 1) It may be scanned with a different (generally, more primitive) shell
> than that which the user is used to (i.e., an old 'sh' variant - or
> maybe a "POSIX" mode shell - rather than bash)
> 2) The "%" character is special in crontab. There may be other "magic"
> characters as well.
>
> That all said, I found something today that I find puzzling. I have
> something like the following in a crontab line:
>
> . someFile;~/bin/someProgram
>
> Now, this fails, with message "someFile not found". If I change it to:
>
> . ./someFile;~/bin/someProgram
>
> It works. What is interesting here is that, according to "man bash", the
> current directory is not searched (for the "." command) if the shell is in
> POSIX mode. This, then, would account for the need for the "./". But if
> that was the case, then you'd expect the "~" thing to fail, since ~
> expansion isn't POSIX.
>
> So, why does is it OK with the ~ expansion, but not with finding someFile
> in the current directory (w/o using "./") ?
The point is that with crontab your PATH will be set to a minimalistic value
> It is well known that cron jobs (as listed in your crontab file) run with a
> very limited environment and that you have to end up specifying a lot of
> things that ordinarily (I.e., when run from the usual interactive command
> line) "just work". It is also well known that the command line itself
> (I.e., the actual text listed in the crontab file) can be problematic; it
> may not work as expected, due to two factors:
> 1) It may be scanned with a different (generally, more primitive) shell
> than that which the user is used to (i.e., an old 'sh' variant - or
> maybe a "POSIX" mode shell - rather than bash)
> 2) The "%" character is special in crontab. There may be other "magic"
> characters as well.
>
> That all said, I found something today that I find puzzling. I have
> something like the following in a crontab line:
>
> . someFile;~/bin/someProgram
>
> Now, this fails, with message "someFile not found". If I change it to:
>
> . ./someFile;~/bin/someProgram
>
> It works. What is interesting here is that, according to "man bash", the
> current directory is not searched (for the "." command) if the shell is in
> POSIX mode. This, then, would account for the need for the "./". But if
> that was the case, then you'd expect the "~" thing to fail, since ~
> expansion isn't POSIX.
>
> So, why does is it OK with the ~ expansion, but not with finding someFile
> in the current directory (w/o using "./") ?
which contains a few system folders only (e.g. PATH=/usr/bin:/bin). And the
'.' (source) command looks for commands in the directories _defined_ in PATH
if no absolute or relative path is given.
Usually (when starting scripts) I explicitly specify the working directory
in the crontab file and also define the interpreter explicitly (cd ... &&
ksh program), and I also define the relevant PATH explicitly in the script.
Janis
Kaz Kylheku
Aug 2, 2017, 9:24:16 AM8/2/17
to
On 2017-08-02, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <201708020...@kylheku.com>,
> Kaz Kylheku <398-81...@kylheku.com> wrote:
>>On 2017-08-02, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>> It works. What is interesting here is that, according to "man bash", the
>>> current directory is not searched (for the "." command) if the shell is in
>>> POSIX mode. This, then, would account for the need for the "./". But if
>>> that was the case, then you'd expect the "~" thing to fail, since ~
>>> expansion isn't POSIX.
>>
>>"Tilde expansion" is POSIX.
>>
>>http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01
>
> OK, so you are asserting that the shell that parses the command line is,
> indeed, bash-in-posix-mode. Right?
If it is Bash, then it's in POSIX mode, since it's not falling back on
> In article <201708020...@kylheku.com>,
> Kaz Kylheku <398-81...@kylheku.com> wrote:
>>On 2017-08-02, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>> It works. What is interesting here is that, according to "man bash", the
>>> current directory is not searched (for the "." command) if the shell is in
>>> POSIX mode. This, then, would account for the need for the "./". But if
>>> that was the case, then you'd expect the "~" thing to fail, since ~
>>> expansion isn't POSIX.
>>
>>"Tilde expansion" is POSIX.
>>
>>http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01
>
> OK, so you are asserting that the shell that parses the command line is,
> indeed, bash-in-posix-mode. Right?
the current directory when not finding the script in PATH.
Janis Papanagnou
Aug 2, 2017, 9:41:08 AM8/2/17
to
On 02.08.2017 15:24, Kaz Kylheku wrote:
> On 2017-08-02, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> In article <201708020...@kylheku.com>,
>> Kaz Kylheku <398-81...@kylheku.com> wrote:
>>> On 2017-08-02, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>>> It works. What is interesting here is that, according to "man bash", the
>>>> current directory is not searched (for the "." command) if the shell is in
>>>> POSIX mode. This, then, would account for the need for the "./". But if
>>>> that was the case, then you'd expect the "~" thing to fail, since ~
>>>> expansion isn't POSIX.
>>>
>>> "Tilde expansion" is POSIX.
>>>
>>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01
>>
>> OK, so you are asserting that the shell that parses the command line is,
>> indeed, bash-in-posix-mode. Right?
>
> If it is Bash, then it's in POSIX mode, since it's not falling back on
> the current directory when not finding the script in PATH.
Without explicitly defined path (i.e. if there's no '/' in the program
> On 2017-08-02, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> In article <201708020...@kylheku.com>,
>> Kaz Kylheku <398-81...@kylheku.com> wrote:
>>> On 2017-08-02, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>>> It works. What is interesting here is that, according to "man bash", the
>>>> current directory is not searched (for the "." command) if the shell is in
>>>> POSIX mode. This, then, would account for the need for the "./". But if
>>>> that was the case, then you'd expect the "~" thing to fail, since ~
>>>> expansion isn't POSIX.
>>>
>>> "Tilde expansion" is POSIX.
>>>
>>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01
>>
>> OK, so you are asserting that the shell that parses the command line is,
>> indeed, bash-in-posix-mode. Right?
>
> If it is Bash, then it's in POSIX mode, since it's not falling back on
> the current directory when not finding the script in PATH.
path) shells search for executable (or sourced) files in the PATH only.
(According to ad hoc tests[*] bash is no exception here.)
Janis
[*] GNU bash, version 4.2.25
Kenny McCormack
Aug 2, 2017, 9:58:38 AM8/2/17
to
In article <olskpd$lgc$1...@news-1.m-online.net>,
Janis Papanagnou <janis_pa...@hotmail.com> tried his best with:
...
--
If it seems like I'm not responding to some moronic criticism that you've
posted in response to one of my posts, be aware that I do not debate with idiots.
It doesn't mean you've won anything...
Janis Papanagnou <janis_pa...@hotmail.com> tried his best with:
...
>Without explicitly defined path (i.e. if there's no '/' in the program
>path) shells search for executable (or sourced) files in the PATH only.
>(According to ad hoc tests[*] bash is no exception here.)
You fail Reading Comprehension 101.
>path) shells search for executable (or sourced) files in the PATH only.
>(According to ad hoc tests[*] bash is no exception here.)
--
If it seems like I'm not responding to some moronic criticism that you've
posted in response to one of my posts, be aware that I do not debate with idiots.
It doesn't mean you've won anything...
Kaz Kylheku
Aug 2, 2017, 10:01:02 AM8/2/17
to
function "execvp"). It's a search for a script file to load. (The script
file need not even have execute permissions, by the way.)
The shell . command mimics the execvp behavior by using PATH.
Bash falls back on just resolving the path name in the current directory
if the PATH search fails; this is suppressed in POSIX mode.
Kenny McCormack
Aug 2, 2017, 10:17:27 AM8/2/17
to
...
The moral seems to be: Always use "./", even though bash will DTRT anyway.
--
"There's no chance that the iPhone is going to get any significant market share. No chance." - Steve Ballmer
>The . command isn't a search for an executable (like with the C library
>function "execvp"). It's a search for a script file to load. (The script
>file need not even have execute permissions, by the way.)
>
>The shell . command mimics the execvp behavior by using PATH.
>
>Bash falls back on just resolving the path name in the current directory
>if the PATH search fails; this is suppressed in POSIX mode.
Quite so.
>function "execvp"). It's a search for a script file to load. (The script
>file need not even have execute permissions, by the way.)
>
>The shell . command mimics the execvp behavior by using PATH.
>
>Bash falls back on just resolving the path name in the current directory
>if the PATH search fails; this is suppressed in POSIX mode.
The moral seems to be: Always use "./", even though bash will DTRT anyway.
--
"There's no chance that the iPhone is going to get any significant market share. No chance." - Steve Ballmer
Janis Papanagnou
Aug 2, 2017, 10:52:02 AM8/2/17
to
On 02.08.2017 16:00, Kaz Kylheku wrote:
>
> Bash falls back on just resolving the path name in the current directory
> if the PATH search fails; this is suppressed in POSIX mode.
Hmm.. - not sure what I have tested before, but you are right that bash
>
> Bash falls back on just resolving the path name in the current directory
> if the PATH search fails; this is suppressed in POSIX mode.
(as opposed to, e.g., ksh) seems to behave non-standard here.
"If file does not contain a <slash>, the shell shall use the search
path specified by PATH to find the directory containing file."
Janis
Kaz Kylheku
Aug 2, 2017, 12:49:01 PM8/2/17
to
On 2017-08-02, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <201708020...@kylheku.com>,
> Kaz Kylheku <398-81...@kylheku.com> wrote:
> ...
>>The . command isn't a search for an executable (like with the C library
>>function "execvp"). It's a search for a script file to load. (The script
>>file need not even have execute permissions, by the way.)
>>
>>The shell . command mimics the execvp behavior by using PATH.
>>
>>Bash falls back on just resolving the path name in the current directory
>>if the PATH search fails; this is suppressed in POSIX mode.
>
> Quite so.
>
> The moral seems to be: Always use "./", even though bash will DTRT anyway.
A agree with the "RT" because there is hardly any downside.
> Kaz Kylheku <398-81...@kylheku.com> wrote:
> ...
>>The . command isn't a search for an executable (like with the C library
>>function "execvp"). It's a search for a script file to load. (The script
>>file need not even have execute permissions, by the way.)
>>
>>The shell . command mimics the execvp behavior by using PATH.
>>
>>Bash falls back on just resolving the path name in the current directory
>>if the PATH search fails; this is suppressed in POSIX mode.
>
> Quite so.
>
> The moral seems to be: Always use "./", even though bash will DTRT anyway.
The dot command is not used for ordinary command execution where
the user will fall victim to something in the current directory
if it is searched.
What is rather surprising is that . use the PATH *at all*.
How stupid, really.
The naive expectation is that . <whatever> is giving a path
name to a file, no different from cat <whatever>.
Should Python, Lisp, Lua, Ruby ... all use PATH to look for loaded
script files? How about the C compiler: why not resolve #include
using PATH.
It's a gratuitously random design decision.
Kenny McCormack
Aug 2, 2017, 12:54:54 PM8/2/17
to
>A agree with the "RT" because there is hardly any downside.
>The dot command is not used for ordinary command execution where
>the user will fall victim to something in the current directory
>if it is searched.
>
>What is rather surprising is that . use the PATH *at all*.
>How stupid, really.
Yup.
>The dot command is not used for ordinary command execution where
>the user will fall victim to something in the current directory
>if it is searched.
>
>What is rather surprising is that . use the PATH *at all*.
>How stupid, really.
>The naive expectation is that . <whatever> is giving a path
>name to a file, no different from cat <whatever>.
>
>Should Python, Lisp, Lua, Ruby ... all use PATH to look for loaded
>script files? How about the C compiler: why not resolve #include
>using PATH.
>
>It's a gratuitously random design decision.
Consider:
bash $ echo 'echo hello' > ls
bash $ . ls
bash: ????: command not found
bash $
Not exactly expected behavior...
--
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof.
- John Kenneth Galbraith -
Janis Papanagnou
Aug 2, 2017, 1:34:42 PM8/2/17
to
On 02.08.2017 18:48, Kaz Kylheku wrote:
> [ dot scripts in bash don't require path components for file ]
> The dot command is not used for ordinary command execution where
> the user will fall victim to something in the current directory
> if it is searched.
This is certainly true for bash (and most shells). Note, though, that
ksh has a [non-standard] extension; you can also call "ksh functions"
with the dot command - this would lead to the conflict you mention
here if it would allow non-standard behaviour without a slash as part
of the file reference. (Bash, which inherited a lot of ksh features,
would have issues to adopt this feature.)
>
> What is rather surprising is that . use the PATH *at all*.
Strange indeed. I know of no rationale for that. - Anyone?
Janis
> [...]
> [ dot scripts in bash don't require path components for file ]
> A agree with the "RT" because there is hardly any downside.
Yes, the error you (other-shell) get is a strong indication for that.
> The dot command is not used for ordinary command execution where
> the user will fall victim to something in the current directory
> if it is searched.
ksh has a [non-standard] extension; you can also call "ksh functions"
with the dot command - this would lead to the conflict you mention
here if it would allow non-standard behaviour without a slash as part
of the file reference. (Bash, which inherited a lot of ksh features,
would have issues to adopt this feature.)
>
> What is rather surprising is that . use the PATH *at all*.
Janis
> [...]
Pyt T.
Aug 3, 2017, 8:48:58 AM8/3/17
to
On Wed, 2 Aug 2017 12:01:41 +0000 (UTC), Kenny McCormack <gaz...@shell.xmission.com> wrote:
> ..
be executed by /bin/sh". On that system /bin/sh is a symlink to
/bin/bash. In man bash I read "If bash is invoked with the name sh, it
tries to mimic the startup behavior of historical versions of sh as
closely as possible, while conforming to the POSIX standard as well.
So if you don't change the SHELL variable in your cron environment you'll be
using bash in POSIX mode.
> ..
> 1) It may be scanned with a different (generally, more primitive) shell
> than that which the user is used to (i.e., an old 'sh' variant - or
> maybe a "POSIX" mode shell - rather than bash)
On a fedora system I read in man 5 crontab "The entire command .. will
> than that which the user is used to (i.e., an old 'sh' variant - or
> maybe a "POSIX" mode shell - rather than bash)
be executed by /bin/sh". On that system /bin/sh is a symlink to
/bin/bash. In man bash I read "If bash is invoked with the name sh, it
tries to mimic the startup behavior of historical versions of sh as
closely as possible, while conforming to the POSIX standard as well.
So if you don't change the SHELL variable in your cron environment you'll be
using bash in POSIX mode.
Martijn Dekker
Aug 3, 2017, 10:41:22 AM8/3/17
to
In article <olt2f8$pjo$1...@news-1.m-online.net>,
It comes in handy for a library of shell functions which might be
installed in different locations on different systems.
- M.
installed in different locations on different systems.
- M.
Kaz Kylheku
Aug 3, 2017, 11:43:58 AM8/3/17
to
have a PATH-like search variable, not for that variable to *be* PATH.
Your C compiler searches for headers in different locations without
involving PATH.
(Moreover, PATH, without additional semantics, wouldn't be powerful
enough to express the difference between #include "..." and <...>).
Various scripting languages can search for modules and source files
in configurable places without PATH being involved.
Make can search for inferred prerequisites; it uses VPATH, not PATH.
Janis Papanagnou
Aug 3, 2017, 12:00:00 PM8/3/17
to
On 03.08.2017 17:43, Kaz Kylheku wrote:
> On 2017-08-03, Martijn Dekker <mar...@inlv.demon.nl> wrote:
>> In article <olt2f8$pjo$1...@news-1.m-online.net>,
>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>
>>> On 02.08.2017 18:48, Kaz Kylheku wrote:
>>>> What is rather surprising is that . use the PATH *at all*.
>>>
>>> Strange indeed. I know of no rationale for that. - Anyone?
>>
>> It comes in handy for a library of shell functions which might be
>> installed in different locations on different systems.
>
> Yes; but that's only the rationale for part of it: the requirement to
> have a PATH-like search variable, not for that variable to *be* PATH.
Ksh for example has FPATH for function library directories. (But
> On 2017-08-03, Martijn Dekker <mar...@inlv.demon.nl> wrote:
>> In article <olt2f8$pjo$1...@news-1.m-online.net>,
>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>
>>> On 02.08.2017 18:48, Kaz Kylheku wrote:
>>>> What is rather surprising is that . use the PATH *at all*.
>>>
>>> Strange indeed. I know of no rationale for that. - Anyone?
>>
>> It comes in handy for a library of shell functions which might be
>> installed in different locations on different systems.
>
> Yes; but that's only the rationale for part of it: the requirement to
> have a PATH-like search variable, not for that variable to *be* PATH.
doesn't seem to use it in case of sourcing ksh functions, in favour
of PATH; maybe due to consistency considerations?) - But sourcing
functions is a "newer" ksh feature (1993) and the PATH relevance in
sourcing quite historic (IIRC).
>
> Your C compiler searches for headers in different locations without
> involving PATH.
command line explicitly?
Janis
> [...]
Barry Margolin
Aug 3, 2017, 1:35:06 PM8/3/17
to
script, so you could package a script together with libraries of
functions that it uses.
But scripts can't easily tell what directory they're in (there are
kludgey ways for scripts to try to figure this out, but they have
failure modes), so maybe using PATH was seen as a workaround -- if you
find the main script via PATH, then the same search would also find the
library files to source them. Of course, this could also fail
spectacularly if an earlier directory in PATH has a script with the same
name (but that's true of lots of things that search PATH).
It also allows you to put scripts that you source from .profile,
.bashrc, etc. in a directory like ~/bin. That way you don't have to write
. ~/bin/script1
. ~/bin/script2
...
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Thomas 'PointedEars' Lahn
Aug 3, 2017, 6:06:36 PM8/3/17
to
Kaz Kylheku wrote:
> What is rather surprising is that . use the PATH *at all*.
> How stupid, really.
No, as I only discovered recently, it is very useful for includes, i.e. code
> What is rather surprising is that . use the PATH *at all*.
> How stupid, really.
reuse (here: ~/bin/includes/).
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
Kenny McCormack
Aug 3, 2017, 7:13:33 PM8/3/17
to
In article <100127320....@PointedEars.de>,
path-ish variable could be useful, in some circumstances. However, my
sense is that it is actually a rarely used functionality; most people do not
go that far into shell programming. When you start getting that far into
it, it is usually time to switch to a more sane language (e.g., AWK, Perl,
etc).
Rather, the problem is that it double-teams on the usual executable "PATH"
variable. There's no particularly good reason for that; they should have
used a different variable (e.g., FPATH or whatever it is in "ksh").
Furthermore, I think the usual "Not having . in PATH" issue shouldn't apply
here. I, of course, understand fully the reasons why the current directory
should not be in the executable $PATH, but there's simply no reason why the
following should not behave as expected:
$ cd /tmp
As you can see, with this example, I am arguing all of the following:
1) It should use some other variable (not $PATH, which finds, surprise!
surprise! executables). There's no sensible reason why shell
source files should be intermixed with binary executables in, say
/bin, /usr/bin, etc.
and
2) The current directory should always be searched first, because
that's what people expect with the . command. This is different
from the expected behavior for a normal executables search.
and
3) It seems pretty clear to me that what happened is that very early
on, when Unix was young, somebody decided it would be a good idea
to have a search path for . files, but didn't really think it
through and just decided to re-use $PATH for that purpose. This
can be seen now to have been a bad decision.
--
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy of the church so decides."
- Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -
Thomas 'PointedEars' Lahn <use...@PointedEars.de> wrote:
>Kaz Kylheku wrote:
>
>> What is rather surprising is that . use the PATH *at all*.
>> How stupid, really.
>
>No, as I only discovered recently, it is very useful for includes, i.e. code
>reuse (here: ~/bin/includes/).
I don't think anyone is denying that having . searching some kind of
>Kaz Kylheku wrote:
>
>> What is rather surprising is that . use the PATH *at all*.
>> How stupid, really.
>
>No, as I only discovered recently, it is very useful for includes, i.e. code
>reuse (here: ~/bin/includes/).
path-ish variable could be useful, in some circumstances. However, my
sense is that it is actually a rarely used functionality; most people do not
go that far into shell programming. When you start getting that far into
it, it is usually time to switch to a more sane language (e.g., AWK, Perl,
etc).
Rather, the problem is that it double-teams on the usual executable "PATH"
variable. There's no particularly good reason for that; they should have
used a different variable (e.g., FPATH or whatever it is in "ksh").
Furthermore, I think the usual "Not having . in PATH" issue shouldn't apply
here. I, of course, understand fully the reasons why the current directory
should not be in the executable $PATH, but there's simply no reason why the
following should not behave as expected:
$ cd /tmp
$ echo 'echo hello' > ls
$ . ls
As you can see, with this example, I am arguing all of the following:
1) It should use some other variable (not $PATH, which finds, surprise!
surprise! executables). There's no sensible reason why shell
source files should be intermixed with binary executables in, say
/bin, /usr/bin, etc.
and
2) The current directory should always be searched first, because
that's what people expect with the . command. This is different
from the expected behavior for a normal executables search.
and
3) It seems pretty clear to me that what happened is that very early
on, when Unix was young, somebody decided it would be a good idea
to have a search path for . files, but didn't really think it
through and just decided to re-use $PATH for that purpose. This
can be seen now to have been a bad decision.
--
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy of the church so decides."
- Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -
Thomas 'PointedEars' Lahn
Aug 4, 2017, 6:07:27 AM8/4/17
to
Kenny McCormack wrote:
> Thomas 'PointedEars' Lahn <use...@PointedEars.de> wrote:
>> Kaz Kylheku wrote:
>>> What is rather surprising is that . use the PATH *at all*.
>>> How stupid, really.
>> No, as I only discovered recently, it is very useful for includes, i.e.
>> code reuse (here: ~/bin/includes/).
>
> I don't think anyone is denying that having . searching some kind of
> path-ish variable could be useful, in some circumstances. However, my
> sense is that it is actually a rarely used functionality; most people do
> not go that far into shell programming. When you start getting that far
> into it, it is usually time to switch to a more sane language (e.g., AWK,
> Perl, etc).
A matter of *opinion*. If I “source” a shell script, I am executing it in a
> Thomas 'PointedEars' Lahn <use...@PointedEars.de> wrote:
>> Kaz Kylheku wrote:
>>> What is rather surprising is that . use the PATH *at all*.
>>> How stupid, really.
>> No, as I only discovered recently, it is very useful for includes, i.e.
>> code reuse (here: ~/bin/includes/).
>
> I don't think anyone is denying that having . searching some kind of
> path-ish variable could be useful, in some circumstances. However, my
> sense is that it is actually a rarely used functionality; most people do
> not go that far into shell programming. When you start getting that far
> into it, it is usually time to switch to a more sane language (e.g., AWK,
> Perl, etc).
specific way. There is no good reason that I would need to know its path,
no good reason that it should not be searched in all directories where
otherwise executable files are searched.
> Rather, the problem is that it double-teams on the usual executable "PATH"
> variable. There's no particularly good reason for that; they should have
> used a different variable (e.g., FPATH or whatever it is in "ksh").
> […] there's simply no reason why the following should not behave as
> expected:
>
> $ cd /tmp
> $ echo 'echo hello' > ls
> $ . ls
What did you expect to happen?
>
> $ cd /tmp
> $ echo 'echo hello' > ls
> $ . ls
Janis Papanagnou
Aug 4, 2017, 6:31:02 AM8/4/17
to
On 04.08.2017 12:07, Thomas 'PointedEars' Lahn wrote:
> Kenny McCormack wrote:
>
>> Thomas 'PointedEars' Lahn <use...@PointedEars.de> wrote:
>>> Kaz Kylheku wrote:
>>>> What is rather surprising is that . use the PATH *at all*.
>>>> How stupid, really.
>>> No, as I only discovered recently, it is very useful for includes, i.e.
>>> code reuse (here: ~/bin/includes/).
>>
>> I don't think anyone is denying that having . searching some kind of
>> path-ish variable could be useful, in some circumstances. However, my
>> sense is that it is actually a rarely used functionality; most people do
>> not go that far into shell programming. When you start getting that far
>> into it, it is usually time to switch to a more sane language (e.g., AWK,
>> Perl, etc).
>
> A matter of *opinion*. If I “source” a shell script, I am executing it in a
> specific way. There is no good reason that I would need to know its path,
> no good reason that it should not be searched in all directories where
> otherwise executable files are searched.
>
>> Rather, the problem is that it double-teams on the usual executable "PATH"
>> variable. There's no particularly good reason for that; they should have
>> used a different variable (e.g., FPATH or whatever it is in "ksh").
>
> Why should shell scripts be treated differently than other programs?
As you say, it's a specific way executing it. The point he is making is that
> Kenny McCormack wrote:
>
>> Thomas 'PointedEars' Lahn <use...@PointedEars.de> wrote:
>>> Kaz Kylheku wrote:
>>>> What is rather surprising is that . use the PATH *at all*.
>>>> How stupid, really.
>>> No, as I only discovered recently, it is very useful for includes, i.e.
>>> code reuse (here: ~/bin/includes/).
>>
>> I don't think anyone is denying that having . searching some kind of
>> path-ish variable could be useful, in some circumstances. However, my
>> sense is that it is actually a rarely used functionality; most people do
>> not go that far into shell programming. When you start getting that far
>> into it, it is usually time to switch to a more sane language (e.g., AWK,
>> Perl, etc).
>
> A matter of *opinion*. If I “source” a shell script, I am executing it in a
> specific way. There is no good reason that I would need to know its path,
> no good reason that it should not be searched in all directories where
> otherwise executable files are searched.
>
>> Rather, the problem is that it double-teams on the usual executable "PATH"
>> variable. There's no particularly good reason for that; they should have
>> used a different variable (e.g., FPATH or whatever it is in "ksh").
>
> Why should shell scripts be treated differently than other programs?
you can execute shell scripts in an own shell instance by invoking it as
sh a_script # and not: sh ./a_script
and in a similar vein (with the exception to be executed in the current shell
environment) he expected this to be also possible [per standard behaviour]
. a_script # and not: . ./a_script
i.e. to directly name the file to be executed.
Elsethread there was already mentioned that the sourced scripts do not even
need execute permissions, so they have more the characteristic of a file than
a program [to be looked up per PATH].
As you say, it's probably a matter of opinion. A rationale for the given way
would in any way be helpful.
>
>> […] there's simply no reason why the following should not behave as
>> expected:
>>
>> $ cd /tmp
>> $ echo 'echo hello' > ls
>> $ . ls
>
> What did you expect to happen?
Janis
Helmut Waitzmann
Aug 4, 2017, 9:39:47 AM8/4/17
to
gaz...@shell.xmission.com (Kenny McCormack):
> Furthermore, I think the usual "Not having . in PATH" issue shouldn't apply
> here. I, of course, understand fully the reasons why the current directory
> should not be in the executable $PATH,
I think, the same security problems with having '.' in the PATH
(or behaving, as if it were appended to the PATH) apply to
searching for shell scripts to be sourced, as well.
> but there's simply no reason why the following should not behave
> as expected:
>
> $ cd /tmp
> $ echo 'echo hello' > ls
> $ . ls
It will only work, when both of the following two conditions hold:
(1) '.' is searched (either explicitly as part of the PATH or
implicitly).
(2) The script is not found searching the PATH entries, which are
searched before the current directory.
To get the file sourced without any search in a number of
directories, the following commands will do
$ echo 'echo hello' > ls
$ . ./ls
And should it be essential (for some external reason) to have
exactly the same file name in the redirection as well as in the
source command without the need to specify './ls', then one might
write
$ # There is a filepath in the variable "script", maybe without
$ # a directory component. If that's the case, prepend './':
$ #
$ test -z "${script##*/*}" || script=./"$script"
$ echo 'echo hello' > "$script"
$ . "$script"
> Furthermore, I think the usual "Not having . in PATH" issue shouldn't apply
> here. I, of course, understand fully the reasons why the current directory
> should not be in the executable $PATH,
(or behaving, as if it were appended to the PATH) apply to
searching for shell scripts to be sourced, as well.
> but there's simply no reason why the following should not behave
> as expected:
>
> $ cd /tmp
> $ echo 'echo hello' > ls
> $ . ls
(1) '.' is searched (either explicitly as part of the PATH or
implicitly).
(2) The script is not found searching the PATH entries, which are
searched before the current directory.
To get the file sourced without any search in a number of
directories, the following commands will do
$ echo 'echo hello' > ls
And should it be essential (for some external reason) to have
exactly the same file name in the redirection as well as in the
source command without the need to specify './ls', then one might
write
$ # There is a filepath in the variable "script", maybe without
$ # a directory component. If that's the case, prepend './':
$ #
$ test -z "${script##*/*}" || script=./"$script"
$ echo 'echo hello' > "$script"
$ . "$script"
Martijn Dekker
Aug 4, 2017, 9:42:27 AM8/4/17
to
In article <201708030...@kylheku.com>,
guessing Stephen Bourne figured he might as well not clutter the
environment with another variable. It was 1977 and every byte counted.
- M.
Kaz Kylheku <398-81...@kylheku.com> wrote:
> On 2017-08-03, Martijn Dekker <mar...@inlv.demon.nl> wrote:
> > In article <olt2f8$pjo$1...@news-1.m-online.net>,
> > Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> >
> >> On 02.08.2017 18:48, Kaz Kylheku wrote:
> >> > What is rather surprising is that . use the PATH *at all*.
> >>
> >> Strange indeed. I know of no rationale for that. - Anyone?
> >
> > It comes in handy for a library of shell functions which might be
> > installed in different locations on different systems.
>
> Yes; but that's only the rationale for part of it: the requirement to
> have a PATH-like search variable, not for that variable to *be* PATH.
Agreed, but PATH seems to be "good enough" for the purpose, so I'm
> On 2017-08-03, Martijn Dekker <mar...@inlv.demon.nl> wrote:
> > In article <olt2f8$pjo$1...@news-1.m-online.net>,
> > Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> >
> >> On 02.08.2017 18:48, Kaz Kylheku wrote:
> >> > What is rather surprising is that . use the PATH *at all*.
> >>
> >> Strange indeed. I know of no rationale for that. - Anyone?
> >
> > It comes in handy for a library of shell functions which might be
> > installed in different locations on different systems.
>
> Yes; but that's only the rationale for part of it: the requirement to
> have a PATH-like search variable, not for that variable to *be* PATH.
guessing Stephen Bourne figured he might as well not clutter the
environment with another variable. It was 1977 and every byte counted.
- M.
Helmut Waitzmann
Aug 4, 2017, 12:00:58 PM8/4/17
to
Helmut Waitzmann <nn.th...@xoxy.net>:
shouldn't do any path searching at all but rather (just like the
redirection operator) expect a file, which name doesn't contain
any '/', in the working directory, then, of course, there is no
security problem. ('bash' can do this: If the 'sourcepath'
option to the 'shopt' builtin command is turned off, the PATH is
not searched.)
> gaz...@shell.xmission.com (Kenny McCormack):
>
>> Furthermore, I think the usual "Not having . in PATH" issue shouldn't apply
>> here. I, of course, understand fully the reasons why the current directory
>> should not be in the executable $PATH,
>
> I think, the same security problems with having '.' in the PATH
> (or behaving, as if it were appended to the PATH) apply to
> searching for shell scripts to be sourced, as well.
>
>> but there's simply no reason why the following should not behave
>> as expected:
>>
>> $ cd /tmp
>> $ echo 'echo hello' > ls
>> $ . ls
>
> It will only work, when both of the following two conditions hold:
>
> (1) '.' is searched (either explicitly as part of the PATH or
> implicitly).
>
> (2) The script is not found searching the PATH entries, which are
> searched before the current directory.
But maybe I misunderstood Kenny. If his proposition is, that '.'
>
>> Furthermore, I think the usual "Not having . in PATH" issue shouldn't apply
>> here. I, of course, understand fully the reasons why the current directory
>> should not be in the executable $PATH,
>
> I think, the same security problems with having '.' in the PATH
> (or behaving, as if it were appended to the PATH) apply to
> searching for shell scripts to be sourced, as well.
>
>> but there's simply no reason why the following should not behave
>> as expected:
>>
>> $ cd /tmp
>> $ echo 'echo hello' > ls
>> $ . ls
>
> It will only work, when both of the following two conditions hold:
>
> (1) '.' is searched (either explicitly as part of the PATH or
> implicitly).
>
> (2) The script is not found searching the PATH entries, which are
> searched before the current directory.
shouldn't do any path searching at all but rather (just like the
redirection operator) expect a file, which name doesn't contain
any '/', in the working directory, then, of course, there is no
security problem. ('bash' can do this: If the 'sourcepath'
option to the 'shopt' builtin command is turned off, the PATH is
not searched.)
Kaz Kylheku
Aug 4, 2017, 5:48:39 PM8/4/17
to
file which allowed him to condense the one-byte { and } tokens to just
BEGIN and END.
Barry Margolin
Aug 5, 2017, 2:24:02 AM8/5/17
to
In article <201708041...@kylheku.com>,
You needed to minimize memory use when the program is running. Verbose
source code has no effect on this.
source code has no effect on this.
0 new messages