4:35 p.m.
For as long as I can remember, the shell builtin 'env' has been useful
for listing all the current environment variables.
Not any more. There's another command called env which does something
different, and the builtin no longer exists.
I mustn't have got the memo. How do I get the old 'env' back?
poc
4:55 p.m.
On 10/6/20 2:35 PM, Patrick O'Callaghan wrote:
For as long as I can remember, the shell builtin 'env' has
been useful
for listing all the current environment variables.
It's not a builtin:
# builtin env
-bash: builtin: env: not a shell builtin
Are you thinking of "set"?
Not any more. There's another command called env which does
something
different, and the builtin no longer exists.
/usr/bin/env prints the list of environment variables for me.
5:04 a.m.
On Tue, 2020-10-06 at 14:55 -0700, Samuel Sieb wrote:
On 10/6/20 2:35 PM, Patrick O'Callaghan wrote:
> For as long as I can remember, the shell builtin 'env' has been useful
> for listing all the current environment variables.
It's not a builtin:
# builtin env
-bash: builtin: env: not a shell builtin
I know. I could have sworn it used to be, but it doesn't matter.
Are you thinking of "set"?
No.
> Not any more. There's another command called env which does
something
> different, and the builtin no longer exists.
/usr/bin/env prints the list of environment variables for me.
Yes, I see it does work. I was mislead by having some shell functions
in my environment, which made it look as if 'env' was dumping a lot of
code. It became clear when I use 'env|less'.
I put it down to galloping senility.
poc
5:45 p.m.
On 2020-10-06 14:35, Patrick O'Callaghan wrote:
For as long as I can remember, the shell builtin 'env' has
been useful
for listing all the current environment variables.
Not any more. There's another command called env which does something
different, and the builtin no longer exists.
I mustn't have got the memo. How do I get the old 'env' back?
poc
Probably as Sam said, you were thinking of "set"
I start all my Raku programs with
1: #!/usr/bin/env raku
Still working properly
5:07 a.m.
On Tue, 2020-10-06 at 15:45 -0700, ToddAndMargo via users wrote:
On 2020-10-06 14:35, Patrick O'Callaghan wrote:
> For as long as I can remember, the shell builtin 'env' has been useful
> for listing all the current environment variables.
>
> Not any more. There's another command called env which does something
> different, and the builtin no longer exists.
>
> I mustn't have got the memo. How do I get the old 'env' back?
>
> poc
Probably as Sam said, you were thinking of "set"
No (see my answer to Samuel).
I start all my Raku programs with
1: #!/usr/bin/env raku
Why? If you aren't adding options to 'env', surely this is the same as
using '/usr/bin/bash'.
poc
4:14 p.m.
On 07Oct2020 11:07, Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
On Tue, 2020-10-06 at 15:45 -0700, ToddAndMargo via users wrote:
> I start all my Raku programs with
> 1: #!/usr/bin/env raku
Why? If you aren't adding options to 'env', surely this is the same as
using '/usr/bin/bash'.
No, this is a standard shebang (#!) hack to accomodate differering
installation paths. The #! requires a fixed absolute path. So things
which are often installed in different places (such as raku above) like
/usr/local/bin or /opt/something and accessed via the user's $PATH
setting, putting in this line makes the script more portable.
It does rely on "env" itself being in /usr/bin, but that is very
common. (Not universal, the a plenty of systems where I make a symlink
from /bin/env to /usr/bin/env to enable _exactly_ ToddAndMargo's
approach.)
Anyway, since env uses $PATH to locate the following executable, this
lets you write scripts for a typically-third-party interpreter portably.
My own common use case is:
#!/usr/bin/env python3
which runs my preferred python3 (usually the one in my personal
~/var/venv/3).
Cheers,
Cameron Simpson <cs(a)cskk.id.au>
5 a.m.
On Thu, 2020-10-08 at 08:14 +1100, Cameron Simpson wrote:
On 07Oct2020 11:07, Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
> On Tue, 2020-10-06 at 15:45 -0700, ToddAndMargo via users wrote:
> > I start all my Raku programs with
> > 1: #!/usr/bin/env raku
>
> Why? If you aren't adding options to 'env', surely this is the same as
> using '/usr/bin/bash'.
No, this is a standard shebang (#!) hack to accomodate differering
installation paths. The #! requires a fixed absolute path. So things
which are often installed in different places (such as raku above) like
/usr/local/bin or /opt/something and accessed via the user's $PATH
setting, putting in this line makes the script more portable.
The user's export environment, including the PATH setting, is
automatically included, even if you have no shebang at all:
$ cat test
type python3
echo $PATH
$ chmod+x test
$ ./test
python3 is /usr/bin/python3
/usr/lib64/qt-3.3/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/poc/.local/bin:/home/poc/bin
poc
1:17 p.m.
On 10/8/20 3:00 AM, Patrick O'Callaghan wrote:
On Thu, 2020-10-08 at 08:14 +1100, Cameron Simpson wrote:
> On 07Oct2020 11:07, Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
>> On Tue, 2020-10-06 at 15:45 -0700, ToddAndMargo via users wrote:
>>> I start all my Raku programs with
>>> 1: #!/usr/bin/env raku
>>
>> Why? If you aren't adding options to 'env', surely this is the same
as
>> using '/usr/bin/bash'.
>
> No, this is a standard shebang (#!) hack to accomodate differering
> installation paths. The #! requires a fixed absolute path. So things
> which are often installed in different places (such as raku above) like
> /usr/local/bin or /opt/something and accessed via the user's $PATH
> setting, putting in this line makes the script more portable.
The user's export environment, including the PATH setting, is
automatically included, even if you have no shebang at all:
$ cat test
type python3
echo $PATH
$ chmod+x test
$ ./test
python3 is /usr/bin/python3
/usr/lib64/qt-3.3/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/poc/.local/bin:/home/poc/bin
I don't understand how your reply is related to the previous discussion.
If you don't have a shebang, then the default is to run it with the shell.
4:55 p.m.
On Thu, 2020-10-08 at 11:17 -0700, Samuel Sieb wrote:
On 10/8/20 3:00 AM, Patrick O'Callaghan wrote:
> On Thu, 2020-10-08 at 08:14 +1100, Cameron Simpson wrote:
> > On 07Oct2020 11:07, Patrick O'Callaghan <pocallaghan(a)gmail.com>
wrote:
> > > On Tue, 2020-10-06 at 15:45 -0700, ToddAndMargo via users wrote:
> > > > I start all my Raku programs with
> > > > 1: #!/usr/bin/env raku
> > >
> > > Why? If you aren't adding options to 'env', surely this is the
same as
> > > using '/usr/bin/bash'.
> >
> > No, this is a standard shebang (#!) hack to accomodate differering
> > installation paths. The #! requires a fixed absolute path. So things
> > which are often installed in different places (such as raku above) like
> > /usr/local/bin or /opt/something and accessed via the user's $PATH
> > setting, putting in this line makes the script more portable.
>
> The user's export environment, including the PATH setting, is
> automatically included, even if you have no shebang at all:
>
> $ cat test
> type python3
> echo $PATH
> $ chmod+x test
> $ ./test
> python3 is /usr/bin/python3
>
/usr/lib64/qt-3.3/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/poc/.local/bin:/home/poc/bin
I don't understand how your reply is related to the previous discussion.
If you don't have a shebang, then the default is to run it with the shell.
I have it straight now. See my answer to Tom H.
poc
2:59 p.m.
On Thu, Oct 8, 2020 at 12:01 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Thu, 2020-10-08 at 08:14 +1100, Cameron Simpson wrote:
> On 07Oct2020 11:07, Patrick O'Callaghan <pocallaghan(a)gmail.com>
> wrote:
>> On Tue, 2020-10-06 at 15:45 -0700, ToddAndMargo via users wrote:
>>>
>>> I start all my Raku programs with
>>> 1: #!/usr/bin/env raku
>>
>> Why? If you aren't adding options to 'env', surely this is the same
>> as using '/usr/bin/bash'.
>
> No, this is a standard shebang (#!) hack to accomodate differering
> installation paths. The #! requires a fixed absolute path. So things
> which are often installed in different places (such as raku above)
> like /usr/local/bin or /opt/something and accessed via the user's
> $PATH setting, putting in this line makes the script more portable.
The user's export environment, including the PATH setting, is
automatically included, even if you have no shebang at all:
$ cat test
type python3
echo $PATH
$ chmod+x test
$ ./test
python3 is /usr/bin/python3
/usr/lib64/qt-3.3/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/poc/.local/bin:/home/poc/bin
You missed "#! requires a fixed absolute path", so you can't use
"#!bash" even though $PATH is set.
Using #!/usr/bin/env bash" supplies "#!" with an absolute path and
runs the script using the first instance of "bash" in $PATH.
4:53 p.m.
On Thu, 2020-10-08 at 21:59 +0200, Tom H wrote:
On Thu, Oct 8, 2020 at 12:01 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
> On Thu, 2020-10-08 at 08:14 +1100, Cameron Simpson wrote:
> > On 07Oct2020 11:07, Patrick O'Callaghan <pocallaghan(a)gmail.com>
> > wrote:
> > > On Tue, 2020-10-06 at 15:45 -0700, ToddAndMargo via users wrote:
> > > > I start all my Raku programs with
> > > > 1: #!/usr/bin/env raku
> > >
> > > Why? If you aren't adding options to 'env', surely this is the
same
> > > as using '/usr/bin/bash'.
> >
> > No, this is a standard shebang (#!) hack to accomodate differering
> > installation paths. The #! requires a fixed absolute path. So things
> > which are often installed in different places (such as raku above)
> > like /usr/local/bin or /opt/something and accessed via the user's
> > $PATH setting, putting in this line makes the script more portable.
>
> The user's export environment, including the PATH setting, is
> automatically included, even if you have no shebang at all:
>
> $ cat test
> type python3
> echo $PATH
> $ chmod+x test
> $ ./test
> python3 is /usr/bin/python3
>
/usr/lib64/qt-3.3/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/poc/.local/bin:/home/poc/bin
You missed "#! requires a fixed absolute path", so you can't use
"#!bash" even though $PATH is set.
Yes, I know.
Using #!/usr/bin/env bash" supplies "#!" with an
absolute path and
runs the script using the first instance of "bash" in $PATH.
OK, I can see the point of that, thanks. I realise that Cameron was
saying the same thing and I hadn't absorbed it.
poc
6:03 p.m.
On 2020-10-08 15:35, Patrick O'Callaghan wrote:
On Thu, 2020-10-08 at 15:29 -0700, ToddAndMargo via users wrote:
> On 2020-10-07 14:14, Cameron Simpson wrote:
>> shebang (#!)
>
> Chuckle. Someone had some fun with that one!
That term has been around in the UNIX world for as long as I can
remember.
poc
A fun one from Raku (Perl 6) is "slurp" and "spurt"
6:36 p.m.
On 10/6/20 2:35 PM, Patrick O'Callaghan wrote:
For as long as I can remember, the shell builtin 'env' has
been useful
for listing all the current environment variables.
Not any more. There's another command called env which does something
different, and the builtin no longer exists.
I mustn't have got the memo. How do I get the old 'env' back?
env roger=rabbit env
Look at the last environment variable.
:m
5:56 a.m.
On Tue, Oct 6, 2020 at 11:35 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
For as long as I can remember, the shell builtin 'env' has been
useful for listing all the current environment variables.
Not any more. There's another command called env which does something
different, and the builtin no longer exists.
I mustn't have got the memo. How do I get the old 'env' back?
Do you have bash-completion enabled? It loads many functions.
6:59 a.m.
On Wed, 2020-10-07 at 12:56 +0200, Tom H wrote:
On Tue, Oct 6, 2020 at 11:35 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
> For as long as I can remember, the shell builtin 'env' has been
> useful for listing all the current environment variables.
>
> Not any more. There's another command called env which does something
> different, and the builtin no longer exists.
>
> I mustn't have got the memo. How do I get the old 'env' back?
Do you have bash-completion enabled? It loads many functions.
I don't think so. I don't recall ever doing that, but it's hard to be
sure. I don't see it in /etc/bashrc, /etc/profile or my home directory
equivalents, though the package is installed. How would I know?
poc
7:57 a.m.
On Wed, Oct 7, 2020 at 2:00 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Wed, 2020-10-07 at 12:56 +0200, Tom H wrote:
> On Tue, Oct 6, 2020 at 11:35 PM Patrick O'Callaghan
> <pocallaghan(a)gmail.com> wrote:
>> For as long as I can remember, the shell builtin 'env' has been
>> useful for listing all the current environment variables.
>>
>> Not any more. There's another command called env which does
>> something different, and the builtin no longer exists.
>>
>> I mustn't have got the memo. How do I get the old 'env' back?
>
> Do you have bash-completion enabled? It loads many functions.
I don't think so. I don't recall ever doing that, but it's hard to be
sure. I don't see it in /etc/bashrc, /etc/profile or my home
directory equivalents, though the package is installed. How would I
know?
It's loaded by "/etc/profile.d/bash_completion.sh", which is sourced
by "/etc/profile" and "/etc/bashrc".
8:39 a.m.
On Wed, 2020-10-07 at 14:57 +0200, Tom H wrote:
On Wed, Oct 7, 2020 at 2:00 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
> On Wed, 2020-10-07 at 12:56 +0200, Tom H wrote:
> > On Tue, Oct 6, 2020 at 11:35 PM Patrick O'Callaghan
> > <pocallaghan(a)gmail.com> wrote:
> > > For as long as I can remember, the shell builtin 'env' has been
> > > useful for listing all the current environment variables.
> > >
> > > Not any more. There's another command called env which does
> > > something different, and the builtin no longer exists.
> > >
> > > I mustn't have got the memo. How do I get the old 'env' back?
> >
> > Do you have bash-completion enabled? It loads many functions.
>
> I don't think so. I don't recall ever doing that, but it's hard to be
> sure. I don't see it in /etc/bashrc, /etc/profile or my home
> directory equivalents, though the package is installed. How would I
> know?
It's loaded by "/etc/profile.d/bash_completion.sh", which is sourced
by "/etc/profile" and "/etc/bashrc".
Neither of those have it, so I guess it's not enabled.
poc
8:51 a.m.
Most of the ridiculous environment embedded functions
come from the "environment-modules" package, which seems to
have reached its claws into all kinds of stuff. If I try
to remove it, I get this list:
Dependencies resolved.
================================================================================
Package Arch Version Repo Size
================================================================================
Removing:
environment-modules x86_64 4.4.1-2.fc32 @fedora 1.6 M
Removing dependent packages:
OpenImageIO x86_64 2.1.17.0-1.fc32 @updates 11 M
blender x86_64 1:2.83.5-5.fc32 @updates 154 M
coin-or-Cbc x86_64 2.10.5-2.fc32 @updates 2.4 M
coin-or-Cgl x86_64 0.60.3-1.fc32 @fedora 1.1 M
coin-or-Clp x86_64 1.17.5-1.fc32 @fedora 2.5 M
digikam x86_64 7.0.0-1.fc32 @updates 149 M
digikam-doc noarch 7.0.0-1.fc32 @updates 0
digikam-libs x86_64 7.0.0-1.fc32 @updates 34 M
mp x86_64 3.1.0-26.20200215git71c21a5.fc32 @fedora 3.6 M
opencv x86_64 4.2.0-7.fc32 @updates 10 M
opencv-contrib x86_64 4.2.0-7.fc32 @updates 16 M
opencv-core x86_64 4.2.0-7.fc32 @updates 19 M
opencv-devel x86_64 4.2.0-7.fc32 @updates 6.3 M
scl-utils x86_64 1:2.0.2-13.fc32 @fedora 62 k
Transaction Summary
================================================================================
Remove 15 Packages
7:27 a.m.
On Wed, Oct 7, 2020 at 3:39 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Wed, 2020-10-07 at 14:57 +0200, Tom H wrote:
>
> It's loaded by "/etc/profile.d/bash_completion.sh", which is sourced
> by "/etc/profile" and "/etc/bashrc".
Neither of those have it, so I guess it's not enabled.
Don't you have "for i in /etc/profile.d/*.sh ..." for-loops in
"/etc/profile" and "/etc/bashrc"?
4:44 p.m.
On Thu, 2020-10-08 at 14:27 +0200, Tom H wrote:
On Wed, Oct 7, 2020 at 3:39 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
> On Wed, 2020-10-07 at 14:57 +0200, Tom H wrote:
> > It's loaded by "/etc/profile.d/bash_completion.sh", which is
sourced
> > by "/etc/profile" and "/etc/bashrc".
>
> Neither of those have it, so I guess it's not enabled.
Don't you have "for i in /etc/profile.d/*.sh ..." for-loops in
"/etc/profile" and "/etc/bashrc"?
Now you mention it, yes. That's where it's coming from.
poc
1303
days inactive
1305
days old
22 comments
7 participants
participants (7)
-
Cameron Simpson -
Mike Wright -
Patrick O'Callaghan -
Samuel Sieb -
ToddAndMargo -
Tom H -
Tom Horsley