Two bugs(?) in the MSYS shell

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Two bugs(?) in the MSYS shell

Greg Jung
1. I only recently tried "$ make -j 4" multiprocessor option with MSYS and discovered that it hangs.  Then the processes remain even after I killed the terminal process from another msys shell. 
2. environment variable that start with "+" get transformed in an way which is werd (and inconvenient). 
In gnudatalanguage (GDL) we use "+{path}" values in  to initialize a recursive
directory search path.  When run from a DOS shell there is of course no change in the variable
and the following resuls:

~~~~
GDL> print,getenv("GDL_LIBRARY")
+D:/programs/gnudatalanguage/lib
GDL> print,!Path
D:/home/greg/coyote/public;D:/home/greg/coyote;D:/home/greg/testsuite/benchmark;D:/home/greg/testsui
te;D:/home/greg;D:/programs/gnudatalanguage/lib/astronv61/pro/debug;D:/programs/gnudatalanguage/lib/
astronv61/pro;D:/programs/gnudatalanguage/lib/dicom;D:/programs/gnudatalanguage/lib/envi;D:/programs
/gnudatalanguage/lib/new;D:/programs/gnudatalanguage/lib/testsuite/benchmark;D:/programs/gnudatalang
uage/lib/testsuite;D:/programs/gnudatalanguage/lib
~~~~

the intializing routine used expand_path("+{library location}) to bring in all subdirectories.
MSYS modifies the environment variable with a "+" by inserting the native path to /usr, as such:

~~~~
greg@Homerw7 /d/programs/gnudatalanguage
$ uname --a
MINGW32_NT-6.1 HOMERW7 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys

greg@Homerw7 /d/programs/gnudatalanguage
$ gdl
% Function not found: PATH_SEP
print,getenv("GDL_LIBRARY")
+D;E:\mingw\msys\1.0\programs\gnudatalanguage\lib
print,!path
E:\mingw\msys\1.0\programs\gnudatalanguage\lib
~~~~

just reporting: there's no urgency from my perspective.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Two bugs(?) in the MSYS shell

Eli Zaretskii
> Date: Mon, 16 Mar 2015 22:52:57 -0700
> From: Greg Jung <[hidden email]>
>
> 1. I only recently tried "$ make -j 4" multiprocessor option with MSYS and
> discovered that it hangs. Then the processes remain even after I killed the
> terminal process from another msys shell.

Find a newer build of MSYS Make than the one provided on the MinGW
site.  I use such a build with -jN with no problems for several years.

> 2. environment variable that start with "+" get transformed in an way which is
> werd (and inconvenient).
> In gnudatalanguage (GDL) we use "+{path}" values in to initialize a recursive
> directory search path. When run from a DOS shell there is of course no change
> in the variable
> and the following resuls:
>
> ~~~~
> GDL> print,getenv("GDL_LIBRARY")
> +D:/programs/gnudatalanguage/lib
> GDL> print,!Path
> D:/home/greg/coyote/public;D:/home/greg/coyote;D:/home/greg/testsuite/benchmark;D:/home/greg/testsui
> te;D:/home/greg;D:/programs/gnudatalanguage/lib/astronv61/pro/debug;D:/programs/gnudatalanguage/lib/
> astronv61/pro;D:/programs/gnudatalanguage/lib/dicom;D:/programs/gnudatalanguage/lib/envi;D:/programs
> /gnudatalanguage/lib/new;D:/programs/gnudatalanguage/lib/testsuite/benchmark;D:/programs/gnudatalang
> uage/lib/testsuite;D:/programs/gnudatalanguage/lib
> ~~~~
>
> the intializing routine used expand_path("+{library location}) to bring in all
> subdirectories.
> MSYS modifies the environment variable with a "+" by inserting the native path
> to /usr, as such:
>
> ~~~~
> greg@Homerw7 /d/programs/gnudatalanguage
> $ uname --a
> MINGW32_NT-6.1 HOMERW7 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys
>
> greg@Homerw7 /d/programs/gnudatalanguage
> $ gdl
> % Function not found: PATH_SEP
> print,getenv("GDL_LIBRARY")
> +D;E:\mingw\msys\1.0\programs\gnudatalanguage\lib
> print,!path
> E:\mingw\msys\1.0\programs\gnudatalanguage\lib
> ~~~~
>
> just reporting: there's no urgency from my perspective.

I'm not sure I understand the situation, so here are a few questions
to clarify that:

 . Why are you using D:/foo/bar instead of /d/foo/bar format?  AFAIU,
   if you use the latter, this problem will be gone.

 . Are you running GDL from MSYS Bash, or the MSYS Bash from within
   GDL?  If so, why?  MinGW programs are not supposed to do that as a
   matter of habit, precisely due to the issues you mention.

 . If you don't invoke GDL from Bash nor Bash from GDL, then I'm
   afraid I don't understand how come the MSYS path expansion comes
   into play here.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Two bugs(?) in the MSYS shell

Greg Jung


On Tue, Mar 17, 2015 at 12:40 AM, Eli Zaretskii <[hidden email]> wrote:
> Date: Mon, 16 Mar 2015 22:52:57 -0700
> From: Greg Jung <[hidden email]>
>
> 1. I only recently tried "$ make -j 4" multiprocessor option with MSYS and
> discovered that it hangs. Then the processes remain even after I killed the
> terminal process from another msys shell.

Find a newer build of MSYS Make than the one provided on the MinGW
site.  I use such a build with -jN with no problems for several years.

> 2. environment variable that start with "+" get transformed in an way which is
> werd (and inconvenient).
> In gnudatalanguage (GDL) we use "+{path}" values in to initialize a recursive
> directory search path. When run from a DOS shell there is of course no change
> in the variable
> and the following resuls:
>
> ~~~~
> GDL> print,getenv("GDL_LIBRARY")
> +D:/programs/gnudatalanguage/lib
> GDL> print,!Path
> D:/home/greg/coyote/public;D:/home/greg/coyote;D:/home/greg/testsuite/benchmark;D:/home/greg/testsui
> te;D:/home/greg;D:/programs/gnudatalanguage/lib/astronv61/pro/debug;D:/programs/gnudatalanguage/lib/
> astronv61/pro;D:/programs/gnudatalanguage/lib/dicom;D:/programs/gnudatalanguage/lib/envi;D:/programs
> /gnudatalanguage/lib/new;D:/programs/gnudatalanguage/lib/testsuite/benchmark;D:/programs/gnudatalang
> uage/lib/testsuite;D:/programs/gnudatalanguage/lib
> ~~~~
>
> the intializing routine used expand_path("+{library location}) to bring in all
> subdirectories.
> MSYS modifies the environment variable with a "+" by inserting the native path
> to /usr, as such:
>
> ~~~~
> greg@Homerw7 /d/programs/gnudatalanguage
> $ uname --a
> MINGW32_NT-6.1 HOMERW7 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys
>
> greg@Homerw7 /d/programs/gnudatalanguage
> $ gdl
> % Function not found: PATH_SEP
> print,getenv("GDL_LIBRARY")
> +D;E:\mingw\msys\1.0\programs\gnudatalanguage\lib
> print,!path
> E:\mingw\msys\1.0\programs\gnudatalanguage\lib
> ~~~~
>
> just reporting: there's no urgency from my perspective.

I'm not sure I understand the situation, so here are a few questions
to clarify that:

 . Why are you using D:/foo/bar instead of /d/foo/bar format?  AFAIU,
   if you use the latter, this problem will be gone.

 . Are you running GDL from MSYS Bash, or the MSYS Bash from within
   GDL?  If so, why?  MinGW programs are not supposed to do that as a
   matter of habit, precisely due to the issues you mention. 
 . If you don't invoke GDL from Bash nor Bash from GDL, then I'm
   afraid I don't understand how come the MSYS path expansion comes
   into play here.


Is this the actual path expansion policy?  This is not how its laid out; path expansion refers to arguments and not to the whole environment.  Perhaps the version I'm using was in an experimental state.  I run the program from msys after I've built it to check it's health; the variable is set up as D:/ because it is to be run normally from DOS shell.  Or from the bash that runs under cmd.exe based on the old NTbash.  As I said, there's no real need for me here; I'm just trying to learn more about the situation.
The program can spawn a CMD.exe shell and capture stdout, which could be used in a platform-independent manner, so its actually useful  to run from a bash shell.  The cygwin
version can only use xlib graphics.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Two bugs(?) in the MSYS shell

Eli Zaretskii
> Date: Wed, 18 Mar 2015 02:24:33 -0700
> From: Greg Jung <[hidden email]>
>
> Is this the actual path expansion policy? This is not how its laid out; path
> expansion refers to arguments and not to the whole environment.

It refers to both, AFAIK.  At least that's what I see on my system
with MSYS.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Two bugs(?) in the MSYS shell

Earnie Boyd
> From: Eli Zaretskii
> > Date: Wed, 18 Mar 2015 02:24:33 -0700
> > From: Greg Jung
> >
> > Is this the actual path expansion policy? This is not how its laid
> > out; path expansion refers to arguments and not to the whole
environment.
>
> It refers to both, AFAIK.  At least that's what I see on my system with
MSYS.
>

There is a small set of environment variables that are modified by MSYS and
those are ones where the environment variable in Windows and POSIX were
common, e.g. PATH, and required for operating a POSIX environment.  A string
with D:/some/path will be converted to D:;C:/PATH/TO/MSYS/ROOT/some/path
because : is the list separator in POSIX and ; is the list separator in
Windows.  Note the C: in my example is assuming that is the device where
MSYS is installed.

--
Earnie


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Two bugs(?) in the MSYS shell

Eli Zaretskii
> From: "Earnie" <[hidden email]>
> Date: Wed, 18 Mar 2015 13:17:20 -0400
>
> > From: Eli Zaretskii
> > > Date: Wed, 18 Mar 2015 02:24:33 -0700
> > > From: Greg Jung
> > >
> > > Is this the actual path expansion policy? This is not how its laid
> > > out; path expansion refers to arguments and not to the whole
> environment.
> >
> > It refers to both, AFAIK.  At least that's what I see on my system with
> MSYS.
> >
>
> There is a small set of environment variables that are modified by MSYS and
> those are ones where the environment variable in Windows and POSIX were
> common, e.g. PATH, and required for operating a POSIX environment.

That's not exactly what I see here.  Observe:

  $ export FOO=/d/gnu
  $ /d/usr/bin/env | fgrep FOO
  FOO=d:/gnu

("/d/usr/bin/env.exe" is a MinGW port of GNU 'env'.)  Does MSYS know
about "$FOO"?  I hope not.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Two bugs(?) in the MSYS shell

Earnie Boyd
> From: Eli Zaretskii [mailto:[hidden email]]
>
> > From: "Earnie" <[hidden email]>
> > Date: Wed, 18 Mar 2015 13:17:20 -0400
> >
> > > From: Eli Zaretskii
> > > > Date: Wed, 18 Mar 2015 02:24:33 -0700
> > > > From: Greg Jung
> > > >
> > > > Is this the actual path expansion policy? This is not how its laid
> > > > out; path expansion refers to arguments and not to the whole
> > environment.
> > >
> > > It refers to both, AFAIK.  At least that's what I see on my system
> > > with
> > MSYS.
> > >
> >
> > There is a small set of environment variables that are modified by
> > MSYS and those are ones where the environment variable in Windows and
> > POSIX were common, e.g. PATH, and required for operating a POSIX
> environment.
>
> That's not exactly what I see here.  Observe:
>
>   $ export FOO=/d/gnu
>   $ /d/usr/bin/env | fgrep FOO
>   FOO=d:/gnu
>

A better example is:

$ export FOO=/d/foo
$ cmd //c set | findstr FOO
FOO=d:/foo

> ("/d/usr/bin/env.exe" is a MinGW port of GNU 'env'.)  Does MSYS know about
> "$FOO"?  I hope not.

I guess I was just too smart about it back whenever and now think I
shouldn't have done that.  Thanks for the kick in the pants.

Earnie


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe