/etc/profile

[Achim Gratz]

I'm removing the Windows PATH in my startup scripts since there's nothing in
there that I think should be accessible from Cygwin.

For (t)csh this is easy enough to do with dropping a script into /etc/profile.d
that gets executed first, but there's no such provision for sh and the ilk since
PATH is set up already before it get there. Now, unless profile gets changed I
can still cut off "/usr/local/bin:/usr/bin:" with a profile.d script, but I
think it might be preferrable that the Windows path gets recorded into
ORIGINAL_PATH or some similar name at the beginning of profile. It would then
be a simple matter to later add the Windows path where appropriate, but I don't
think the default path should have it at all.

Also, there are two things in profile that may admit slight improvement (a place
where LC_COLLATE is specified just for one command and better guarding against a
missing or non-cdable /etc/skel).

Patch:
--- /etc/defaults/etc/profile 2012-02-27 22:03:33.000000000 +0100
+++ /etc/profile 2012-08-21 12:12:42.617969800 +0200
@@ -29,7 +29,8 @@
# software to override 'system' software.
# Modifying these default path settings can be done in different ways.
# To learn more about startup files, refer to your shell's man page.
-PATH="/usr/local/bin:/usr/bin:${PATH}"
+ORIGINAL_PATH=$PATH
+PATH="/usr/local/bin:/usr/bin"
MANPATH="/usr/local/man:/usr/share/man:/usr/man:${MANPATH}"
INFOPATH="/usr/local/info:/usr/share/info:/usr/info:${INFOPATH}"

@@ -75,14 +76,17 @@
echo
echo "They will never be overwritten nor automatically updated."
echo
- cd /etc/skel || echo "WARNING: Failed attempt to cd into /etc/skel!"
- /usr/bin/find . -type f | while read f; do
- fDest=${f#.}
- if [ ! -e "${HOME}${fDest}" -a ! -L "${HOME}${fDest}" ]; then
- /usr/bin/install -D -p -v "${f}" "${HOME}/${fDest}"
- fi
- done
- unset fDest
+ if ! cd /etc/skel ; then
+ echo "WARNING: Failed attempt to cd into /etc/skel!"
+ else
+ /usr/bin/find . -type f | while read f; do
+ fDest=${f#.}
+ if [ ! -e "${HOME}${fDest}" -a ! -L "${HOME}${fDest}" ]; then
+ /usr/bin/install -D -p -v "${f}" "${HOME}/${fDest}"
+ fi
+ done
+ unset fDest
+ fi
else
echo "${HOME} could not be created."
{ [ -d "${TEMP}" ] && HOME="${TEMP}"; } ||
@@ -103,7 +107,7 @@
# Shell dependent settings
profile_d ()
{
- for file in $(export LC_COLLATE=C; echo /etc/profile.d/*.$1); do
+ for file in $(LC_COLLATE=C echo /etc/profile.d/*.$1); do
[ -e "${file}" ] && . "${file}"
done
unset file



Regards,
Achim.

[Eric Blake]

Post by Achim Gratz
I'm removing the Windows PATH in my startup scripts since there's nothing in
there that I think should be accessible from Cygwin.

Unfortunately, at least your windows system dll directory has to be on
PATH, or cygwin1.dll will fail to load, so blindly removing ALL windows
paths from PATH is wrong.

Post by Achim Gratz
Also, there are two things in profile that may admit slight improvement (a place
where LC_COLLATE is specified just for one command and better guarding against a
missing or non-cdable /etc/skel).

A missing /etc/skel is a sign of mis-installation, but extra guards
won't hurt, I guess. But you are wrong about the LC_COLLATE command
having no effect. Remember, the shell is required to expand globbing
prior to executing a command, but that LC_COLLATE affects how globbing
is performed. Therefore, you MUST separate the assignment from
LC_COLLATE from the globbing, if the globbing is to be affected (for
that matter, if LC_ALL is set, then it overrides LC_COLLATE, so it may
be better to patch this particular usage to set LC_ALL instead of
LC_COLLATE).

Post by Achim Gratz
@@ -103,7 +107,7 @@
# Shell dependent settings
profile_d ()
{
- for file in $(export LC_COLLATE=C; echo /etc/profile.d/*.$1); do
+ for file in $(LC_COLLATE=C echo /etc/profile.d/*.$1); do

Given my above arguments, if this changes at all, it should change to:
for file in $(LC_ALL=C; echo /etc/profile.d/*.$1); do

but that is not safe for files containing whitespace. If you want
safety, then we should avoid the $() and use globbing directly, although
it gets much longer with something like this:

saved_LC_ALL=$LC_ALL
set_LC_ALL=${LC_ALL+set}
LC_ALL=C
for file in /etc/profile.d/*.$1; do
if test $set_LC_ALL
LC_ALL=$saved_LC_ALL
else
unset LC_ALL
fi
# original loop body
done
if test $set_LC_ALL
LC_ALL=$saved_LC_ALL
else
unset LC_ALL
fi
unset saved_LC_ALL set_LC_ALL

[Achim Gratz]

Post by Eric Blake
Unfortunately, at least your windows system dll directory has to be on
PATH, or cygwin1.dll will fail to load, so blindly removing ALL windows
paths from PATH is wrong.

At that point cygwin1.dll is already loaded and so far I haven't seen anything
not working due to that change. But yes, I didn't think of that, so I'm curious
why it seems to work as nicely as it does.

Post by Eric Blake
A missing /etc/skel is a sign of mis-installation, but extra guards
won't hurt, I guess.

Specifically, that fail would induce the copy of files from whatever the current
directory is into whatever HOME is set to. I guess that could potentially cause
a lot of damage...

Post by Eric Blake
But you are wrong about the LC_COLLATE command
having no effect.

I didn't say it doesn't have an effect.

Post by Eric Blake
Remember, the shell is required to expand globbing
prior to executing a command, but that LC_COLLATE affects how globbing
is performed.

Yes, I missed that globbing was performed before the change in locale treatment
went active.

Post by Eric Blake
Therefore, you MUST separate the assignment from
LC_COLLATE from the globbing, if the globbing is to be affected (for
that matter, if LC_ALL is set, then it overrides LC_COLLATE, so it may
be better to patch this particular usage to set LC_ALL instead of
LC_COLLATE).

Yes, that seems like a good idea, even though I can't imagine why LC_ALL would
already be set at that point... OK, it gets imported when I set it from Windows
System Properties. I'll have to think about unsetting these unconditionally,
then.

Post by Eric Blake
but that is not safe for files containing whitespace. If you want
safety, then we should avoid the $() and use globbing directly, although

That saves us a fork, so it may even be a net win, on the other hand forking a
subshell saves us the restore of LC_ALL... How about this, then (which doesn't
fork and handles spaces correctly):

profile_d ()
{
for file in /etc/profile.d/*.$1 ; do
[ -e "${file}" ] && . "${file}"
done
unset file
}

and then calling it like this:

LC_ALL=C profile_d *.sh

The "unset file" could also go if the call included a "file= ",
I'd think.


Thanks for having a look.


Regards,
Achim.

[James Johnston]

-----Original Message-----
Sent: Tuesday, August 21, 2012 14:39
Subject: Re: /etc/profile

Post by Eric Blake
Unfortunately, at least your windows system dll directory has to be on
PATH, or cygwin1.dll will fail to load, so blindly removing ALL
windows paths from PATH is wrong.

At that point cygwin1.dll is already loaded and so far I haven't seen anything
not working due to that change. But yes, I didn't think of that, so I'm curious
why it seems to work as nicely as it does.

Read section "Search order for desktop applications" at "Dynamic-Link
Library Search Order" at
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).as
px

Bottom line, you don't need system32 in the path for DLL loading to work. I
seem to recall that some earlier versions of Windows actually did not
include system32 in the PATH by default.

[Eric Blake]

Post by Achim Gratz
That saves us a fork, so it may even be a net win, on the other hand forking a
subshell saves us the restore of LC_ALL... How about this, then (which doesn't
profile_d ()
{
for file in /etc/profile.d/*.$1 ; do
[ -e "${file}" ] && . "${file}"
done
unset file
}
LC_ALL=C profile_d *.sh

Sorry, POSIX requires that to leave LC_ALL set after the function call,
which is not what you want (bash behaves differently according to
whether it was started as bash or sh).

$ ksh -c 'foo=bar; blah() { :; }; foo=baz blah; echo $foo'
baz
$ bash -c 'foo=bar; blah() { :; }; foo=baz blah; echo $foo'
bar
$ sh -c 'foo=bar; blah() { :; }; foo=baz blah; echo $foo'
baz

[Achim Gratz]

Post by Eric Blake
Sorry, POSIX requires that to leave LC_ALL set after the function call,

Interesting. Where is that specified?

Post by Eric Blake
which is not what you want (bash behaves differently according to
whether it was started as bash or sh).

OK, it wasn't the same as the original invocation anyway since now the
scripts would be called with LC_ALL=C set (which might be exactly what
you wanted, but still...) — so perhaps:

profile_d ()
{
_LC_SAVE_="$LC_ALL"
LC_ALL=C
for file in /etc/profile.d/*.$1 ; do
[ -e "${file}" ] && LC_ALL="$_LC_SAVE_" . "${file}"
done
LC_ALL="$_LC_SAVE_"
unset file
unset _LC_SAVE_
}

That leaves the original function calls the same as well.


Regards,
Achim.

[Eric Blake]

Post by Achim Gratz

Post by Eric Blake
Sorry, POSIX requires that to leave LC_ALL set after the function call,

Interesting. Where is that specified?

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05

When a function is executed, it shall have the syntax-error and
variable-assignment properties described for special built-in utilities
in the enumerated list at the beginning of Special Built-In Utilities.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_14

Variable assignments specified with special built-in utilities remain in
effect after the built-in completes; this shall not be the case with a
regular built-in or other utility.

[Achim Gratz]

Post by Eric Blake

Post by Achim Gratz
Interesting. Where is that specified?

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05
When a function is executed, it shall have the syntax-error and
variable-assignment properties described for special built-in utilities
in the enumerated list at the beginning of Special Built-In Utilities.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_14
Variable assignments specified with special built-in utilities remain in
effect after the built-in completes; this shall not be the case with a
regular built-in or other utility.

Thank you.


Regards,
Achim.

[Earnie Boyd]

Post by Achim Gratz

Post by Eric Blake
Unfortunately, at least your windows system dll directory has to be on
PATH, or cygwin1.dll will fail to load, so blindly removing ALL windows
paths from PATH is wrong.

At that point cygwin1.dll is already loaded and so far I haven't seen anything
not working due to that change. But yes, I didn't think of that, so I'm curious
why it seems to work as nicely as it does.

Right, I remove windows PATHS from my PATH after starting with my
.profile and .bash_profile files. Besides, the Windows library search
order will search for known DLL in known directories automagicly.

[David Sastre Medina]

Post by Achim Gratz
I'm removing the Windows PATH in my startup scripts since there's nothing in
there that I think should be accessible from Cygwin.
For (t)csh this is easy enough to do with dropping a script into /etc/profile.d
that gets executed first, but there's no such provision for sh and the ilk since
PATH is set up already before it get there. Now, unless profile gets changed I
can still cut off "/usr/local/bin:/usr/bin:" with a profile.d script, but I
think it might be preferrable that the Windows path gets recorded into
ORIGINAL_PATH or some similar name at the beginning of profile. It would then
be a simple matter to later add the Windows path where appropriate, but I don't
think the default path should have it at all.
Also, there are two things in profile that may admit slight improvement (a place
where LC_COLLATE is specified just for one command and better guarding against a
missing or non-cdable /etc/skel).

All three changes will be available in the next release (profile_d
modification taken from your last version in this thread).

Thanks.

[Achim Gratz]

Post by David Sastre Medina
All three changes will be available in the next release (profile_d
modification taken from your last version in this thread).
Thanks.

Thank you. If you'd rather have a complete patch, let me know and I'll
post it or send it to you via email, as you prefer.


Regards,
Achim.

[David Sastre Medina]

Post by Achim Gratz
If you'd rather have a complete patch, let me know and I'll
post it or send it to you via email, as you prefer.

I'm having this on github now for easier handling.
Check https://github.com/dsastrem/base-files.git

[Achim Gratz]

Post by David Sastre Medina
I'm having this on github now for easier handling.
Check https://github.com/dsastrem/base-files.git

Ah, nice. Everythings OK, thank you.


Regards,
Achim.

[Achim Gratz]

Post by David Sastre Medina
I'm having this on github now for easier handling.
Check https://github.com/dsastrem/base-files.git

I've checked the objections raised in this thread and also an older
thread concerning the LC_ALL handling w.r.t. /etc/profile.d and handling
of PS1. I think these are all valid, patches to do implement them are
attached. Also, posh didn't run the scripts in /etc/profile.d at all,
which I think is an error even given the limited focus of it. Also, zsh
runs in sh compatibility mode when it sources /etc/profile, so zsh
extensions shouldn't be used. I've kept sourcing *.zsh for now since
the only script that comes with the distribution does not use zsh
extensions, but I think it would be cleaner if this wasn't done. Zsh
might also run in ksh compatibility mode, but I don't know how to check
for that and if it's worth the trouble.

[Achim Gratz]

Achim Gratz writes:
[...]
Hit send too soon... here's the patch set again without the typos.

[Daniel Colascione]

Post by David Sastre Medina

Post by Achim Gratz
I'm removing the Windows PATH in my startup scripts since there's nothing in
there that I think should be accessible from Cygwin.
For (t)csh this is easy enough to do with dropping a script into /etc/profile.d
that gets executed first, but there's no such provision for sh and the ilk since
PATH is set up already before it get there. Now, unless profile gets changed I
can still cut off "/usr/local/bin:/usr/bin:" with a profile.d script, but I
think it might be preferrable that the Windows path gets recorded into
ORIGINAL_PATH or some similar name at the beginning of profile. It would then
be a simple matter to later add the Windows path where appropriate, but I don't
think the default path should have it at all.
Also, there are two things in profile that may admit slight improvement (a place
where LC_COLLATE is specified just for one command and better guarding against a
missing or non-cdable /etc/skel).

All three changes will be available in the next release (profile_d
modification taken from your last version in this thread).

Post by Achim Gratz
I'm removing the Windows PATH in my startup scripts since there's nothing in
there that I think should be accessible from Cygwin.

People execute Windows programs using Cygwin all the time. With this
change, basic things like "cmd" and "notepad" will fail to work.
Working with Windows programs is the *point* of Cygwin. I really don't
think this change should go into the default startup scripts.

[Achim Gratz]

Post by Daniel Colascione
People execute Windows programs using Cygwin all the time. With this
change, basic things like "cmd" and "notepad" will fail to work.
Working with Windows programs is the *point* of Cygwin. I really don't
think this change should go into the default startup scripts.

The change is about giving users a choice. You can now drop a script
into profile.d that just does:

PATH="${PATH}:${ORIGINAL_PATH}"

and have exactly the same behaviour as you have now (and David might
consider installing that by default). Or you don't and are not bothered
by the useless stuff corporate IT adds to Windows PATH without even
checking that it works correctly on Windows, let alone together with
Cygwin.


Regards,
Achim.

[Christopher Faylor]

Post by Achim Gratz

Post by Daniel Colascione
People execute Windows programs using Cygwin all the time. With this
change, basic things like "cmd" and "notepad" will fail to work.
Working with Windows programs is the *point* of Cygwin. I really don't
think this change should go into the default startup scripts.

The change is about giving users a choice. You can now drop a script
PATH="${PATH}:${ORIGINAL_PATH}"
and have exactly the same behaviour as you have now (and David might
consider installing that by default). Or you don't and are not bothered
by the useless stuff corporate IT adds to Windows PATH without even
checking that it works correctly on Windows, let alone together with
Cygwin.

If we are changing a longstanding behavior then I agree with Daniel that
this is a bad idea. You're just asking for people to be confused.

If you want to make it easy to remove the Windows PATH then I guess I
can see why that would be useful but it seems like anyone for whom this
would be an issue would know how to do this anyway so I don't see why we
have to go to great lengths to accommodate anyone who wants this.

cgf

[Achim Gratz]

Post by Christopher Faylor
If we are changing a longstanding behavior then I agree with Daniel that
this is a bad idea. You're just asking for people to be confused.

Again, I'm not arguing for changing the default. In fact, as long as
ORIGINAL_PATH stays available it might even still be added to PATH in
/etc/profile, although I still think it is cleaner to install
/etc/profile.d/00_add_windows_path.sh in base-files with the contents
I've shown. If it's already been added then removing it with just the
means of a POSIX shell is a bit involved, but even that would be a
possibility.

Post by Christopher Faylor
If you want to make it easy to remove the Windows PATH then I guess I
can see why that would be useful but it seems like anyone for whom this
would be an issue would know how to do this anyway so I don't see why we
have to go to great lengths to accommodate anyone who wants this.

The issue is that to effect that customization I have to change a file
that is not supposed to be changed (since that prevents any updates from
getting to it automatically).


Regards,
Achim.

[Andrew DeFaria]

The issue is that to effect that customization I have to change a file that is not supposed to be changed (since that prevents any updates from getting to it automatically).

I've long since (circa 1994 or so) had a script called set_path that I
can source to set my path from scratch. My ~/.bashrc calls it. I can add
on different directories as required from my various clients.
Directories only get added to the path if they exist.

Now why can't you do similar? It would not be "changing a file that is
not supposed to be changes" rather it would be changing files that you
own and that should be changed.

It's your environment - take control of it!

[Andrey Repin]

Greetings, Achim Gratz!

Post by Achim Gratz

Post by Daniel Colascione
People execute Windows programs using Cygwin all the time. With this
change, basic things like "cmd" and "notepad" will fail to work.
Working with Windows programs is the *point* of Cygwin. I really don't
think this change should go into the default startup scripts.

The change is about giving users a choice. You can now drop a script
PATH="${PATH}:${ORIGINAL_PATH}"

The point it, I don't want this.
My $PATH is set in Windows, and I do not modify it in startup scripts.


--
WBR,
Andrey Repin (***@freemail.ru) 23.08.2012, <00:44>

Sorry for my terrible english...

[Achim Gratz]

Post by Andrey Repin
Greetings, Achim Gratz!

Post by Achim Gratz

Post by Daniel Colascione
People execute Windows programs using Cygwin all the time. With this
change, basic things like "cmd" and "notepad" will fail to work.
Working with Windows programs is the *point* of Cygwin. I really don't
think this change should go into the default startup scripts.

The change is about giving users a choice. You can now drop a script
PATH="${PATH}:${ORIGINAL_PATH}"

The point it, I don't want this.

You do realise that this is exactly what is done today, just at a
different place, do you?

Post by Andrey Repin
My $PATH is set in Windows, and I do not modify it in startup scripts.

Yes you do, in /etc/profile - check it yourself.


Regards,
Achim.

[David Sastre Medina]

Post by Daniel Colascione

Post by David Sastre Medina

Post by Achim Gratz
I'm removing the Windows PATH in my startup scripts since there's nothing in
there that I think should be accessible from Cygwin.

All three changes will be available in the next release (profile_d
modification taken from your last version in this thread).

People execute Windows programs using Cygwin all the time. With this
change, basic things like "cmd" and "notepad" will fail to work.
Working with Windows programs is the *point* of Cygwin. I really don't
think this change should go into the default startup scripts.

I for one never start windows programs from within a shell, with the
exception of firefox, and for that I registered an entry in the
alternatives system (x-www-browser), however, I take your advice and
I'll give this a second thought, and also would like to hear from
others' opnion wrt to this.
Obviously, ORIGINAL_PATH (as proposed in Achim's patch) would
still hold the native Windows' PATH, so it'd be very easy to include a
(commented?) line using it, so it would be easy to switch it:

#PATH="/usr/local/bin:/usr/bin:${ORIGINAL_PATH}"

[Christopher Faylor]

Post by David Sastre Medina

Post by Daniel Colascione

Post by David Sastre Medina

Post by Achim Gratz
I'm removing the Windows PATH in my startup scripts since there's nothing in
there that I think should be accessible from Cygwin.

All three changes will be available in the next release (profile_d
modification taken from your last version in this thread).

People execute Windows programs using Cygwin all the time. With this
change, basic things like "cmd" and "notepad" will fail to work.
Working with Windows programs is the *point* of Cygwin. I really don't
think this change should go into the default startup scripts.

I for one never start windows programs from within a shell, with the
exception of firefox, and for that I registered an entry in the
alternatives system (x-www-browser), however, I take your advice and
I'll give this a second thought, and also would like to hear from
others' opnion wrt to this.
Obviously, ORIGINAL_PATH (as proposed in Achim's patch) would
still hold the native Windows' PATH, so it'd be very easy to include a
#PATH="/usr/local/bin:/usr/bin:${ORIGINAL_PATH}"

I'll just reiterate what Daniel said again: We can't make things like
cmd or notepad stop working. That would be a disaster.

I wasn't really following the discussion, and don't really want to check
stuff out in git to see what's going on, but if the proposed change just
makes it possible for purists to remove the Windows PATH from the Cygwin
one however that's great. Otherwise, removing the Windows path entirely
really won't please very many people.

cgf

[David Sastre Medina]

Post by Christopher Faylor
I'll just reiterate what Daniel said again: We can't make things like
cmd or notepad stop working. That would be a disaster.
I wasn't really following the discussion, and don't really want to check
stuff out in git to see what's going on, but if the proposed change just
makes it possible for purists to remove the Windows PATH from the Cygwin
one however that's great. Otherwise, removing the Windows path entirely
really won't please very many people.

ACK. I'll keep PATH untouched and see if there are other ways to offer this
functionality as an option.

[Achim Gratz]

Post by Christopher Faylor
I'll just reiterate what Daniel said again: We can't make things like
cmd or notepad stop working. That would be a disaster.

Yes, and nobody proposed otherwise.

Post by Christopher Faylor
I wasn't really following the discussion, and don't really want to check
stuff out in git to see what's going on, but if the proposed change just
makes it possible for purists to remove the Windows PATH from the Cygwin
one however that's great.

OK, here it is again in a nutshell, it has two parts:

1. instead of adding the windows PATH in /etc/profile (which doesn't
need it _at all_), just record it there into ORIGINAL_PATH.

2. Add a script to /etc/profile.d which concatenates the Cygwin and the
windows path to provide the same net result as todays /etc/profile.


I hope this avoids more TLDR;


Regards,
Achim.

[L Anderson]

Post by Achim Gratz

Post by Christopher Faylor
I'll just reiterate what Daniel said again: We can't make things like
cmd or notepad stop working. That would be a disaster.

Yes, and nobody proposed otherwise.

Post by Christopher Faylor
I wasn't really following the discussion, and don't really want to check
stuff out in git to see what's going on, but if the proposed change just
makes it possible for purists to remove the Windows PATH from the Cygwin
one however that's great.

1. instead of adding the windows PATH in /etc/profile (which doesn't
need it _at all_), just record it there into ORIGINAL_PATH.

But I already have my own ORIGINAL_PATH set for my cygwin environment
for my own use

No joy!!

LA