You are not logged in.

#1 2016-06-02 11:35:03

Caldazar
Member
Registered: 2012-06-21
Posts: 38

[SOLVED] Where to put environment vars regarding SystemD

Long story short: I have my own python modules in /usr/local/lib/python3.5/

and 3 instances that run scripts importing from there:

  • Python shell in terminal

  • PyCharm (code-completion, debugging, etc.)

  • Systemd services starting my scripts (as system)

Now I have a myriad of options where to put

PYTHONPATH=/usr/local/lib/python3.5/
1. Export in ~/.bashrc:

Python shell imports my own modules just fine
PyCharm and Systemd don't

2. /etc/environment:

Python shell & PyCharm see it, Python scripts started by SystemD don't

3. Writing it into the service file:

    [Service]
    EnvironmentFile=/etc/environment

It works, but I don't like to repeat myself too much.

4. /etc/systemd/system.conf (=>DefaultEnvironment=):

Only works for Systemd, neither

printenv

nor

sudo printenv

have it.
And besides, writing paths in one line, into a file with tons of other stuff in it just rubs me the wrong way.
I really like /etc/environment because of this. Easy to find, has just one job, easy to edit, great.

Solutions with folders like /user@.service.d, /etc/systemd/system.conf.d/*.conf don't work at all for some reason / I haven't figured it out.

So right now, I've defined PYTHONPATH in two places:

  • /etc/environment and

  • /etc/systemd/system.conf

I'm contemplating about just writing a script that makes Systemd import everything from /etc/environment. Maybe there is even a native way to make Systemd globally recognise this file?

But then, reading some of his blog posts, I fear Lennart might get wind of it and probably send some guys to my home who will "gently" nudge me towards abandoning those files altogether.
(No hate, he has a point with his fixation on unifying a couple of things.)

Question:

So, before I do anything stupid, I'd like to know how you handle this. How is it done properly and what is the most elegant way you can think of?

Last edited by Caldazar (2016-06-03 13:38:03)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#2 2016-06-02 13:02:09

ukhippo
Member
From: Non-paged pool
Registered: 2014-02-21
Posts: 366

Re: [SOLVED] Where to put environment vars regarding SystemD

To be honest, I can't see what's wrong with option 3. It's simple. It works. What's the point of writing a synchronising script and having a "watchdog" waiting to run it? That's just over complicating matters.

Offline

#3 2016-06-02 13:25:49

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: [SOLVED] Where to put environment vars regarding SystemD

Caldazar wrote:

Solutions with folders like /user@.service.d, /etc/systemd/system.conf.d/*.conf don't work at all for some reason / I haven't figured it out.

This seems the best approach to me.  But we can't help you figure out why it's not working for you if you only tell us that these settings "don't work".  What have you done?  Are there any error/log/journal messages?  Did you restart your session?  Are you running the python-script services as user services?


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Online

#4 2016-06-02 14:34:39

Caldazar
Member
Registered: 2012-06-21
Posts: 38

Re: [SOLVED] Where to put environment vars regarding SystemD

ukhippo wrote:

To be honest, I can't see what's wrong with option 3. It's simple. It works.

In practice, it really isn't that bad.
However, it feels too similar to hardcoding a path into a script for me to like it.

It's a no-brainer for an exceptional rule a particular service needs, not so much for a general rule for all my python scripts I run via SystemD.
For those I'd really like to have their standard environment at one centralized place.

Trilby wrote:

[...] we can't help you figure out why it's [putting it in *.d folders] not working for you if you only tell us that these settings "don't work".

I know, I just went over those briefly.

Basically I created such a folder, put a file into it, like 10-defaultpaths.conf, defined a variable in it accordingly and that was about it.

For /etc/systemd/system.conf.d/10-defaultpaths.conf, I believe it was

    DefaultEnvironment="PYTHONPATH=/usr/local/lib/python3.5"

Copied it to /etc/systemd/user.conf.d/, didn't work, not even after reboots, screw it.
I wasn't too sure that this is actually how it is supposed to be done, just from reading the systemd.system.conf manual so I let it fall after a bit of trial and error.

Now that you tell me that this man page was actually the right place to look for a systemwide solution, I'll get deeper into it and report back.

But even if I get it to work, I suspect I'd still have to keep the same var in /etc/environment, so still not the "one place to define it for all" that I was hoping for.

Last edited by Caldazar (2016-06-02 14:51:06)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#5 2016-06-02 14:53:03

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: [SOLVED] Where to put environment vars regarding SystemD

Caldazar wrote:

For /etc/systemd/system.conf.d/10-defaultpaths.conf, I believe it was

    DefaultEnvironment="PYTHONPATH=/usr/local/lib/python3.5"

I can't find any documentation suggesting that path, and conceptually it doesn't make any sense: system.conf is not a systemd unit.  If that DefaultEnvironment line is all you need and you want this for system services, put it in /etc/systemd/system.conf as documented.

Caldazar wrote:

Now that you tell me that this man page was actually the right place to look for a systemwide solution, I'll get deeper into it and report back.

I didn't tell you that.  I asked several questions to gather more information.  So far they've all been left unanswered.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Online

#6 2016-06-02 15:20:53

Caldazar
Member
Registered: 2012-06-21
Posts: 38

Re: [SOLVED] Where to put environment vars regarding SystemD

Trilby wrote:
Caldazar wrote:

For /etc/systemd/system.conf.d/10-defaultpaths.conf, I believe it was

    DefaultEnvironment="PYTHONPATH=/usr/local/lib/python3.5"

I can't find any documentation suggesting that path, and conceptually it doesn't make any sense: system.conf is not a systemd unit.  If that DefaultEnvironment line is all you need and you want this for system services, put it in /etc/systemd/system.conf as documented.

No, actually I can't find any documentation suggesting anything regarding my specific problem.

The man-page I linked to suggests that path, among others, including /etc/systemd/system.conf.

But I'm not even sure whether configuring SystemD is the right route when what I actually want to do is to configure Python in a way SystemD recognises it as well.

So you'd approach it by defining the path in /etc/systemd/system.conf just as I did.

Fine, only that I still have to define it in /etc/environment as well. It works, I just don't consider it as the ideal solution to have the same path at multiple locations.

Last edited by Caldazar (2016-06-02 15:28:13)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#7 2016-06-02 15:32:05

ukhippo
Member
From: Non-paged pool
Registered: 2014-02-21
Posts: 366

Re: [SOLVED] Where to put environment vars regarding SystemD

Caldazar wrote:

For /etc/systemd/system.conf.d/10-defaultpaths.conf, I believe it was

    DefaultEnvironment="PYTHONPATH=/usr/local/lib/python3.5"

That's not a valid snippet; you haven't specified the section the snippet applies to (“[Manager]” in this case)
Try using:

[Manager]
DefaultEnvironment="PYTHONPATH=/usr/local/lib/python3.5"

Offline

#8 2016-06-02 16:37:28

Caldazar
Member
Registered: 2012-06-21
Posts: 38

Re: [SOLVED] Where to put environment vars regarding SystemD

That was my mistake there, thank you!

Now this is better than having it directly in the system.conf file but still ...

I haven't tested it for userspace scripts but I suspect I'd have to do the same in /etc/systemd/user.conf.d/ for that.
If so, together with /etc/environment, we'd need the same variable at 3 different places.

That just looks very un-systemd-like to me, not unifying but actually fragmenting.
That's why I came up with maybe writing a script that reads /etc/environment and then just does a

systemctl import-environment 

for each var right after boot.

Last edited by Caldazar (2016-06-02 16:40:58)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#9 2016-06-02 17:15:07

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: [SOLVED] Where to put environment vars regarding SystemD

Trilby wrote:

I asked several questions to gather more information.  So far they've all been left unanswered.

Caldazar wrote:

I came up with maybe writing a script that reads /etc/environment and then just does a

systemctl import-environment 

for each var right after boot.

And you'd do this for many variables for the system and user daemons.  So now you've gone from having this in three places to many more.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Online

#10 2016-06-02 18:21:56

Caldazar
Member
Registered: 2012-06-21
Posts: 38

Re: [SOLVED] Where to put environment vars regarding SystemD

Trilby wrote:

I asked several questions to gather more information.  So far they've all been left unanswered.

The scripts in question run as root and are spawned by systemd's system scope via timers (e.g backup, clean-caches, etc.).
The services are wanted by graphical.target (which might be wrong, idk)

I activate changes in units with 'daemon-reload' anything else like .config files with a full reboot.

The error I'm looking for to see whether a solution works is to see whether python imports "my-own-module" when started via a systemd service:

sudo systemctl start backup.service
sudo systemctl status backup.service

If PYTHONPATH didn't cascade down to the script, I get a python error  that no module with the name "my-own-module" exists.
Script exits with error => service fails.
If systemd knows about the var,

import my-own-module

within the python script works => script exits without error => service as well. 


Trilby wrote:

And you'd do this for many variables for the system and user daemons.  So now you've gone from having this in three places to many more.

That's not how it plays out in my mind. That doesn't mean a lot as I'm really struggling with all the scopes the environment vars can have, depending on where they are defined.

Let's break it down:
If it is in /etc/environment, pam knows about it. That means it is in the environment of both root and user ('printenv && sudo printenv').
Every program knows about it, no matter whether it is started by root or by user.

Only systemd didn't get the memo. Not its 'user' scope, nor its 'system' scope.

But it's easy to tell systemd about it with

sudo systemctl import-environment PYTHONPATH

Problem is, that only holds for the current session, similar to 'export'.
Systemd doesn't provide anything permanent, which is like we could start a service but not enable it without writing an additional *.conf file

So the import script I'm thinking about would read /etc/environment line by line, extract the varnames and import them all into systemd's 'user' and 'system' scopes.
Run at startup, this would have an similar effect like an 'export within the .bashrc file, only systemwide.

Just one place to define my vars (/etc/environment) and one script to tell systemd about them.

Systemd actually thinks we should add a kernel commandline option (systemd.setenv) to do that. (see https://www.freedesktop.org/software/sy … exec.html# at the bottom)
But come on. Why is it so easy to import into a session but to 'enable' it, kernel option?

Systemd's PAM options don't provide any help either afaict.

That's what I can't wrap my head around. I thought I must have s.th. missed.

Last edited by Caldazar (2016-06-02 21:28:35)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#11 2016-06-02 20:11:07

ukhippo
Member
From: Non-paged pool
Registered: 2014-02-21
Posts: 366

Re: [SOLVED] Where to put environment vars regarding SystemD

I refer you back to my original answer.
As for hardcoding paths, I think /etc/environment is sufficiently well known that it isn't changing anytime soon...

Offline

#12 2016-06-02 21:27:33

Caldazar
Member
Registered: 2012-06-21
Posts: 38

Re: [SOLVED] Where to put environment vars regarding SystemD

Yeah, of course. It is practical.
At this point, if we're not missing s.th very basic, all I can say against it is that it isn't very pleasing aesthetically.

I found this ugly little gap between SystemD and the rest of my system, but no central bridge, just a bunch of different ropes I can hand out to anyone who wants to cross it.

EDIT: I'm also curious why Systemd behaves that way. Not taking environment from the rest of the system and worse, not passing its own vars down to the rest so I could at least get rid of all the duplicate definitions.
If you have any idea, please let me know.

Last edited by Caldazar (2016-06-03 09:10:14)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#13 2016-06-03 10:24:38

Painless
Member
Registered: 2006-02-06
Posts: 233

Re: [SOLVED] Where to put environment vars regarding SystemD

My first thought would be to create a script in /etc/profile.d

Not sure how it would play with systemd.

Offline

#14 2016-06-03 13:37:16

Caldazar
Member
Registered: 2012-06-21
Posts: 38

Re: [SOLVED] Where to put environment vars regarding SystemD

I just tried and can say that the problem with this is its scope. Exports there only get through to user shells like bash.
Not even the python shell sees it, let alone Systemd.

I also tried to run systemctl commands there, which have no effect. It seems really *only* bash & Co shells get affected by this.

But I digged deeper and finally found what I was searching for.


Solution:

---------------------------------------------------------------------------------------------------------------------------------------------
We indeed missed s.th very basic. So easy actually that I now get why it isn't implemented in Systemd.

1. Easy one-liner to import vars from a file

Lennart himself suggested that part of the solution. In hindsight it's obvious.

Lennart Poettering wrote:

systemctl set-environment `cat FILE` should work, no?


2. Make it work for /etc/environment

All we need is to get rid of possible comment sections like in /etc/environment with egrep

systemctl set-environment `cat /etc/environment | egrep -v '^\s*(#|$)'`

3. Make it work in a .service file

This is a bit tricky as systemd generally doesn't execute it's services as bash. So, make do!

Write  '/etc/systemd/system/systemd-setenv.service

[Unit]
Description=Transfers /etc/environment to systemd

[Service]
ExecStart=/usr/bin/bash -c "/usr/bin/systemctl set-environment `/usr/bin/cat /etc/environment | /usr/bin/egrep -v '^\s*(#|$)'`"

[Install]
WantedBy=multi-user.target

4. The permanent solution

Obviously after testing

sudo systemctl enable systemd-setenv.service

Done!

The outcome regarding PYTHONPATH

getenv
sudo getenv
python shell
systemctl show-environment
systemctl --user show-environment

My python-scripts with custom imports execute just fine from a service / timer.

Just one enabled service file reading /etc/environment into systemd's scope

What do you think? Objections? Improvements?  Is it worth the effort?

Last edited by Caldazar (2016-06-03 15:51:59)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#15 2016-06-03 14:23:57

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: [SOLVED] Where to put environment vars regarding SystemD

How is this different from adding /etc/environment as an EnvironmentFile in your systemd conf, again?


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#16 2016-06-03 14:37:07

Caldazar
Member
Registered: 2012-06-21
Posts: 38

Re: [SOLVED] Where to put environment vars regarding SystemD

Eschwartz wrote:

How is this different from adding /etc/environment as an EnvironmentFile in your systemd conf, again?

That option isn't available in systemd configuration as far as I know. It works only in *.service files.
So you can tell each service to import a file, but not systemd as a whole.
There you can only do it by writing each variable into the DefaultEnvironment list.

In both cases that "each" is the part I don't like.

Last edited by Caldazar (2016-06-03 14:39:58)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#17 2016-06-03 14:45:20

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,415

Re: [SOLVED] Where to put environment vars regarding SystemD

But it is there

Nvm didn't read previous discussion closely enough

Last edited by V1del (2016-06-03 14:47:47)

Offline

#18 2016-06-03 17:17:21

ukhippo
Member
From: Non-paged pool
Registered: 2014-02-21
Posts: 366

Re: [SOLVED] Where to put environment vars regarding SystemD

Caldazar wrote:

Write  '/etc/systemd/system/systemd-setenv.service

[Unit]
Description=Transfers /etc/environment to systemd

[Service]
ExecStart=/usr/bin/bash -c "/usr/bin/systemctl set-environment `/usr/bin/cat /etc/environment | /usr/bin/egrep -v '^\s*(#|$)'`"

[Install]
WantedBy=multi-user.target

...

What do you think? Objections? Improvements?  Is it worth the effort?

You don't know when when your setenv service will run at boot, so potentially it could be run after another service that depends on the environment vars causing the dependent service to fail. You can either add "Requires" to all the dependent services, or have the setenv service run earlier in the boot process (the bootup man page shows the target hierarchy).

Last edited by ukhippo (2016-06-03 17:19:54)

Offline

#19 2016-06-03 19:07:30

Raynman
Member
Registered: 2011-10-22
Posts: 1,539

Re: [SOLVED] Where to put environment vars regarding SystemD

You have a useless use of cat there (and you don't need full paths to the binaries in the bash command string).

ukhippo wrote:

You can either add "Requires" to all the dependent services

I think you mean "After". It could be combined with Requires (and then the import service wouldn't have to be enabled explicitly). But this brings us back to adding something to each unit, so I'm guessing Caldazar won't like it smile

Offline

#20 2016-06-03 19:25:21

Caldazar
Member
Registered: 2012-06-21
Posts: 38

Re: [SOLVED] Where to put environment vars regarding SystemD

ukhippo wrote:

You don't know when when your setenv service will run at boot, so potentially it could be run after another service that depends on the environment vars causing the dependent service to fail. You can either add "Requires" to all the dependent services, or have the setenv service run earlier in the boot process (the bootup man page shows the target hierarchy).

Yes, good point, this could indeed become a problem.

Alright, options:

1. add "Requires" to all the dependent services

Exactly Raynman.
Then I'm not better off than with just adding the EnvironmentFile to begin with. Even worse in theory, as this system trusts user input and on top of that obfuscates the root-problem if Requires isn't set.

2. Before=basic.target

For the typical scripts and their targets, this should be be fine. All late boot services (graphical, multi-user, etc) would have to wait for the environment to be set.
According to the manual, I'd have to set DefaultDependencies=no to avoid a dependency short circuit, but other than it sounds alright.

systemd automatically adds dependencies of the types Requires= and After= for this target unit to all services (except for those with DefaultDependencies=no).

Still, it might be too late for some fringe cases, scripts that need to get run early during boot and also have DefaultDependencies=no set.

3. WantedBy=sysinit.target

This is a bit scary to be honest, but again, with setting DefaultDependencies=no, I see no problems. Except

The manual again:

System services pulled in by this target should declare DefaultDependencies=no and specify all their dependencies manually, including access to anything more than a read only root filesystem.

I'm not sure what that means. I do need more than a read only root filesystem: Executable bash programs. Or does "dependencies" in this context mean something else, only other targets?

Am I getting this right? Any additional options?
Right now I'm split between 2 and 3.

Last edited by Caldazar (2016-06-03 19:34:15)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#21 2016-06-03 22:02:05

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: [SOLVED] Where to put environment vars regarding SystemD

Caldazar wrote:
Eschwartz wrote:

How is this different from adding /etc/environment as an EnvironmentFile in your systemd conf, again?

That option isn't available in systemd configuration as far as I know. It works only in *.service files.
So you can tell each service to import a file, but not systemd as a whole.
There you can only do it by writing each variable into the DefaultEnvironment list.

In both cases that "each" is the part I don't like.

Huh, my bad.

That is slightly stupid, IMHO.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#22 2016-06-03 23:14:46

Caldazar
Member
Registered: 2012-06-21
Posts: 38

Re: [SOLVED] Where to put environment vars regarding SystemD

Eschwartz wrote:

That is slightly stupid, IMHO.

Yes, that trench between Systemd's environment and the whole rest looks so artificial, there must be a good reason for it.

Might be that the current system is quite complicated. Or a mess, however you want to see it.
Too much at least for Systemd to bother with anything more than some case to case import options.

That would make sense. I mean I could just do a bare "sudo systemctl import-environment", it's just that this looks like a whole can of worms, even to me.

I wouldn't be too surprised however if Systemd one day takes over the whole environment management altogether.

Last edited by Caldazar (2016-06-03 23:28:19)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#23 2016-06-03 23:35:46

ukhippo
Member
From: Non-paged pool
Registered: 2014-02-21
Posts: 366

Re: [SOLVED] Where to put environment vars regarding SystemD

Raynman wrote:
ukhippo wrote:

You can either add "Requires" to all the dependent services

I think you mean "After".

Oops, my bad. Indeed I did mean "After"

Caldazar wrote:
2. Before=basic.target

...
Still, it might be too late for some fringe cases, scripts that need to get run early during boot and also have DefaultDependencies=no set.

Do you have any of these fringe cases? If not, worry about those later if they should ever turn up.

Caldazar wrote:
3. WantedBy=sysinit.target

This is a bit scary to be honest, but again, with setting DefaultDependencies=no, I see no problems. Except

The manual again:

System services pulled in by this target should declare DefaultDependencies=no and specify all their dependencies manually, including access to anything more than a read only root filesystem.

I'm not sure what that means. I do need more than a read only root filesystem: Executable bash programs. Or does "dependencies" in this context mean something else, only other targets?

I take "read only" to mean "non-writable". After all those early units are running executables of some sort...

Another option would be to inject your own target between sysinit.target and basic.target. That way you could ensure your service is run after sysinit.target has been reached and also runs before any units installed to basic.target.

Offline

#24 2016-06-04 07:22:59

Caldazar
Member
Registered: 2012-06-21
Posts: 38

Re: [SOLVED] Where to put environment vars regarding SystemD

Yes, sysinit.target is definitely too early. Important Systemd services get spawned by that, including 'sysctl' and the journal.
So I'd have to throw a ton of 'After' conditions in there.

The same is true if I'd create a custom target there if I get it right.

A lot of the central stuff gets spawned not earlier than by multi-user.target anyway.
Also given that I can't think of one of said theoretical fringe-cases, even "WantedBy=basic.target" should be more than enough, maybe with a "Before=multi-user.target".(?)

Btw @ Raynman

Raynman wrote:

You have a useless use of cat there

Oh, crap, now I get it. Thank you! That's what happens if you copy & paste your code together, hoping no one will notice.

ExecStart=/usr/bin/bash -c "systemctl set-environment `egrep -v '^\s*(#|$)' /etc/environment`"

I guess that's what you meant?

Last edited by Caldazar (2016-06-04 07:27:06)


4.4.11-1-lts #1 SMP Thu May 19 21:03:24 CEST 2016 x86_64 GNU/Linux
KDE
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst - 24GB RAM

Offline

#25 2016-06-04 10:13:00

Raynman
Member
Registered: 2011-10-22
Posts: 1,539

Re: [SOLVED] Where to put environment vars regarding SystemD

Caldazar wrote:

I guess that's what you meant?

It is. And while we're at it, $(egrep ...) is also generally preferable to the form with backticks.

Offline

Board footer

Powered by FluxBB