mingw-msys — A members only discussion list for the use of MSYS.

Re: [Mingw-msys] [Mingw-users] find lacks -L option

[Andrew P. <and...@gm...>]

Also, find v4.1 runs terribly slowly on my machine. Maybe a newer version
is more efficient.


On Tue, May 7, 2013 at 2:49 PM, Andrew Pennebaker <
and...@gm...> wrote:

>
> You should be able to use ``find /c ...'' without
>>  needing -L.
>>
>
> Yes, this works :)
>
> I just wish I could search from root without worrying about such things.
> Ordinarly, I'd alias find to find -L in my bash profile, but until MSYS
> find gets support for the -L flag, that particular solution is unavailable.
>
> --
> Cheers,
>
> Andrew Pennebaker
> www.yellosoft.us
>



-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: [Mingw-msys] [Mingw-users] find lacks -L option

[Andrew P. <and...@gm...>]

> You should be able to use ``find /c ...'' without
> needing -L.
>

Yes, this works :)

I just wish I could search from root without worrying about such things.
Ordinarly, I'd alias find to find -L in my bash profile, but until MSYS
find gets support for the -L flag, that particular solution is unavailable.

-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: [Mingw-msys] [Mingw-users] find lacks -L option

[Earnie B. <ea...@us...>]

On Tue, May 7, 2013 at 2:36 PM, Andrew Pennebaker wrote:
> I would like `find` to follow the /c/ (C:\) link, where I keep most of my
> data, but the version of `find` included seems to lack the -L option.
>

/c is not a symlink to C:\ it is a mapping of Windows semantics to
POSIX semantics.  You should be able to use ``find /c ...'' without
needing -L.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-msys] [Mingw-users] find lacks -L option

[Andrew P. <and...@gm...>]

I would like `find` to follow the /c/ (C:\) link, where I keep most of my
data, but the version of `find` included seems to lack the -L option.

Could we update MSYS's `find`?

$ find --help
Usage: find [path...] [expression]
default path is the current directory; default expression is -print
expression may consist of:
operators (decreasing precedence; -and is implicit where no others are
given):
      ( EXPR ) ! EXPR -not EXPR EXPR1 -a EXPR2 EXPR1 -and EXPR2
      EXPR1 -o EXPR2 EXPR1 -or EXPR2 EXPR1 , EXPR2
options (always true): -daystart -depth -follow --help
      -maxdepth LEVELS -mindepth LEVELS -mount -noleaf --version -xdev
tests (N can be +N or -N or N): -amin N -anewer FILE -atime N -cmin N
      -cnewer FILE -ctime N -empty -false -fstype TYPE -gid N -group NAME
      -ilname PATTERN -iname PATTERN -inum N -ipath PATTERN -iregex PATTERN
      -links N -lname PATTERN -mmin N -mtime N -name PATTERN -newer FILE
      -nouser -nogroup -path PATTERN -perm [+-]MODE -regex PATTERN
      -size N[bckw] -true -type [bcdpfls] -uid N -used N -user NAME
      -xtype [bcdpfls]
actions: -exec COMMAND ; -fprint FILE -fprint0 FILE -fprintf FILE FORMAT
      -ok COMMAND ; -print -print0 -printf FORMAT -prune -ls
apenneba@NIC-WKS01 ~/Desktop

$ find --help | ack "-L"
ack: No regular expression found.

$ specs find bash git os
Specs:

specs 0.4
https://github.com/mcandre/specs#readme

find --version
GNU find version 4.1

bash --version
GNU bash, version 3.1.0(1)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.

git --version
git version 1.8.0.msysgit.0

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
OS Name:                   Microsoft Windows XP Professional
OS Version:                5.1.2600 Service Pack 3 Build 2600

-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: [Mingw-msys] emmintrin.h: No such file or directory

[Keith M. <kei...@us...>]

On 26 March 2013 10:05, ghtrjhrtj wrote:
[Question about *MinGW*]

1) This question doesn't relate to MSYS.
2) This MSYS specific mailing list is deprecated.

Please raise your issue on the MinGW-Users list:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Mingw-msys] emmintrin.h: No such file or directory

[ghtrjhrtj <cky...@16...>]

when I run 
C:\MinGW\make.exe


it print:


mingw32-gcc -c -msse2 swsse2.c
In file included from swsse2.c:12:
swstriped.h:4:23: emmintrin.h: No such file or directory
C:\MinGW\make.exe: *** [swsse2.o] Error 1




I wonder if you can tell me why.
thanks!


（please forgive me for my poor english!）

Re: [Mingw-msys] problem with make in MSYS

[Earnie B. <ea...@us...>]

Please move this discussion to min...@li....

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-msys] Possible bug? POSIX paths

[Ralf F. <ra...@gm...>]

* BGINFO for X
| 4) Windows path subfolder (ADAM) -> It doesn't works!
| 
| $ ls -la c:\windows\ADAM
| 
| ls: c:windowsADAM: No such file or directory
--<snip-snip>--
| My question is: Why test 4 doesn't work?

Because the backslash is the SHELL quoting character.  It is used to
escape the next character from any special meaning.  In your example,
'w' and 'A' have no special meaning, so the backslash is 'wasted'.

You need to double an unquoted backslash to get a single backslash
into the argument:
  ls -la c:\\windows\\ADAM
or quote it:
  ls -la 'c:\windows\ADAM'

HTH
R'

Re: [Mingw-msys] Possible bug? POSIX paths

[Earnie B. <ea...@us...>]

On Fri, Feb 8, 2013 at 9:26 AM, BGINFO for X <bgi...@kz...> wrote:

This needs discussed at min...@li....  Please
resend to that list.

> Hello,
>
> After reading some documentation about PATHS,
> http://www.mingw.org/wiki/Posix_path_conversion
>
> I have some problems doing a trivial "ls" with windows paths (no spaces).
>
> I have done 5 tests:
>
> 1) Windows path one folder - It works!
>
> $ ls -la c:\windows
>
> ls: c:windows/CSC:
>
> total 23080
>
> drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 .
>
> drwxsr-xr-x 22 k Administradores 16384 Feb 6 16:38 ..
>
> -rw-r--r-- 1 k Administradores 5242934 Nov 5 08:30 BGInfo.bmp
>
> ...
>
>
>
> 2) POSIX path one folder -> It works!
>
> $ ls -la c:/windows
>
> ls: c:/windows/CSC:
>
> total 23080
>
> drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 .
>
> drwxr-xr-x 22 k Administradores 16384 Feb 6 16:38 ..
>
> -rw-r--r-- 1 k Administradores 5242934 Nov 5 08:30 BGInfo.bmp
>
> ...
>
>
> 3) POSIX path subfolder (ADAM) -> It works!
>
> $ ls -la c:/windows/ADAM
>
> total 3384
>
> drwxr-xr-x 37 k Administradores 4096 Mar 20 2012 .
>
> drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 ..
>
> -rwxr-xr-x 2 k Administradores 253952 Nov 20 2010 ADSchemaAnalyzer.exe
>
> ...
>
>
> 4) Windows path subfolder (ADAM) -> It doesn't works!
>
> $ ls -la c:\windows\ADAM
>
> ls: c:windowsADAM: No such file or directory
>
>
> 5) Windows path subfolder (ADAM) QUOTED -> It works!
>
> $ ls -la "c:\windows\ADAM"
>
> total 3384
>
> drwxr-xr-x 37 k Administradores 4096 Mar 20 2012 .
>
> drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 ..
>
> -rwxr-xr-x 2 k Administradores 253952 Nov 20 2010 ADSchemaAnalyzer.exe
>
>
> My question is: Why test 4 doesn't work?
>
> If there is only one folder, it works (test 1).
>
> I don't understand why adding subfolders fails.
>
> Is there any reason?
>
> I'm doing something wrong?
>
>
> Why test 5 works?
>
> I think that quoting here is not necessary.
>
> But In fact I don't mind if works with quotes. My real question is test 4.
>
>
> Thanks a lot.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>



-- 
Earnie
-- https://sites.google.com/site/earnieboyd

[Mingw-msys] Possible bug? POSIX paths

[BGINFO f. X <bgi...@kz...>]

Hello,

 After reading some documentation about PATHS,
http://www.mingw.org/wiki/Posix_path_conversion

 I have some problems doing a trivial "ls" with windows paths (no spaces).

 I have done 5 tests:

 1) Windows path one folder - It works!

$ ls -la c:\windows

ls: c:windows/CSC:

total 23080

drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 .

drwxsr-xr-x 22 k Administradores 16384 Feb 6 16:38 ..

-rw-r--r-- 1 k Administradores 5242934 Nov 5 08:30 BGInfo.bmp

...



2) POSIX path one folder -> It works!

$ ls -la c:/windows

ls: c:/windows/CSC:

total 23080

drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 .

drwxr-xr-x 22 k Administradores 16384 Feb 6 16:38 ..

-rw-r--r-- 1 k Administradores 5242934 Nov 5 08:30 BGInfo.bmp

...


 3) POSIX path subfolder (ADAM) -> It works!

$ ls -la c:/windows/ADAM

total 3384

drwxr-xr-x 37 k Administradores 4096 Mar 20 2012 .

drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 ..

-rwxr-xr-x 2 k Administradores 253952 Nov 20 2010 ADSchemaAnalyzer.exe

...


 4) Windows path subfolder (ADAM) -> It doesn't works!

$ ls -la c:\windows\ADAM

ls: c:windowsADAM: No such file or directory


 5) Windows path subfolder (ADAM) QUOTED -> It works!

$ ls -la "c:\windows\ADAM"

total 3384

drwxr-xr-x 37 k Administradores 4096 Mar 20 2012 .

drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 ..

-rwxr-xr-x 2 k Administradores 253952 Nov 20 2010 ADSchemaAnalyzer.exe


 My question is: Why test 4 doesn't work?

 If there is only one folder, it works (test 1).

I don't understand why adding subfolders fails.

Is there any reason?

I'm doing something wrong?


 Why test 5 works?

I think that quoting here is not necessary.

But In fact I don't mind if works with quotes. My real question is test 4.


 Thanks a lot.

Re: [Mingw-msys] msys-1.18 with basic unicode support

[Ralph <ral...@gm...>]

Just uploaded it to the ticket system, included text from my changelog 
(hopefully its descriptive enough).
Patching is fully automated since i use astyle formatting it would be 
hard if not impossible to apply the patch without the same formatting i 
use (sorry about that but i like my code readable).

Hope you find it usefull.

Regards Revelator

Den 07-02-2013 13:12, Earnie Boyd skrev:
> On Thu, Feb 7, 2013 at 2:59 AM, Ralph wrote:
>> Using kbless patchset from msysgit and a whole slew of work i managed to
>> make a version that supports multibyte
>> and a basic set of unicode functions.
>>
> Please consider using mingw-users to communicate instead of mingw-msys.
>
>> It took quite some work because he was missing a few exports in
>> cygwin.din and the wrappers for the w32api unicode functions where
>> impossible to compile.
>>
>> I also added strtoll and strtoull besides stdint and inttypes to the build.
>>
>> i have tested it against bash zsh and libiconv and they all work and
>> report both multibyte an unicode functionality.
>>
>> I can upload a patch or the modified code for you to try out.
> Add the patchset to the Issues ticket system at
> https://sourceforge.net/p/mingw/bugs/ for consideration.  Please
> consider a proper ChangeLog entry giving kbless the glory he deserves.
>

Re: [Mingw-msys] msys-1.18 with basic unicode support

[Earnie B. <ea...@us...>]

On Thu, Feb 7, 2013 at 2:59 AM, Ralph wrote:
> Using kbless patchset from msysgit and a whole slew of work i managed to
> make a version that supports multibyte
> and a basic set of unicode functions.
>

Please consider using mingw-users to communicate instead of mingw-msys.

> It took quite some work because he was missing a few exports in
> cygwin.din and the wrappers for the w32api unicode functions where
> impossible to compile.
>
> I also added strtoll and strtoull besides stdint and inttypes to the build.
>
> i have tested it against bash zsh and libiconv and they all work and
> report both multibyte an unicode functionality.
>
> I can upload a patch or the modified code for you to try out.

Add the patchset to the Issues ticket system at
https://sourceforge.net/p/mingw/bugs/ for consideration.  Please
consider a proper ChangeLog entry giving kbless the glory he deserves.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

[Mingw-msys] msys-1.18 with basic unicode support

[Ralph <ral...@gm...>]

Using kbless patchset from msysgit and a whole slew of work i managed to 
make a version that supports multibyte
and a basic set of unicode functions.

It took quite some work because he was missing a few exports in 
cygwin.din and the wrappers for the w32api unicode functions where 
impossible to compile.

I also added strtoll and strtoull besides stdint and inttypes to the build.

i have tested it against bash zsh and libiconv and they all work and 
report both multibyte an unicode functionality.

I can upload a patch or the modified code for you to try out.

Revelator

[Mingw-msys] MSYS portable question

[BGINFO f. X <bgi...@kz...>]

Hello,

 I'm trying to create an installation of MSYS portable:

 For example, I copy the 1.0 folder (where resides msys), to C:\.

Then I rename it to C:\MSYSPORTABLE.

Then I launch msys.bat, and all seems that works fine.

 I'm doing it in the right way?Is there something that I need to know for
function properly?

Any drawbacks?

 Thanks a lot.

Re: [Mingw-msys] regarding HOME/END/DELETE keys in msys console

[Earnie B. <ea...@us...>]

On Sun, Dec 30, 2012 at 1:16 AM, ginzzer wrote:

Please discuss this at min...@li... instead of this list.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

[Mingw-msys] regarding HOME/END/DELETE keys in msys console

[ginzzer <gi...@gm...>]

Hi there,
  I just upgraded my msys to the latest version and I figure out the
HOME/END and DELETE keys doesn't really work in the new console (sorry I
didn't remember if it works in the original version too), whenever I
press HOME/END/DELETE, it shows '~' instead. I search online and leads
me to http://www.mingw.org/wiki/Configure_RXVT, I follow the
instructions and tried

1) remove the rxvt.exe, but it doesn't help
2) I modify the ~/.inputrc with the following 
      set completion-query-items 100
      set completion-ignore-case on
      set show-all-if-ambiguous off

      set input-meta on
      set output-meta on
      set convert-meta off
      set bell-style none

      "\e[2~": paste-from-clipboard
      "\e[3~": delete-char
      "\e[5~": beginning-of-history
      "\e[6~": end-of-history
      "\e[7~": beginning-of-line
      "\e[8~": end-of-line

then DELETE key seems work  but HOME/END still doesn't work. 

I have the mingw/msys installed on windows7 x64. Any hint to solve the
problem will be highly appreciated. Thanks.

Re: [Mingw-msys] msysCORE-1.0.18

[Earnie B. <ea...@us...>]

On Wed, Dec 19, 2012 at 4:18 AM, Алексей Павлов wrote:
> Hi!
> With msysCORE-1.0.18 I can't use make with more than 1 job - build
> freezes. On msysCORE-1.0.17 its ok.

Redirecting to the mingw-users list.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

[Mingw-msys] msysCORE-1.0.18

[Алексей П. <al...@gm...>]

Hi!
With msysCORE-1.0.18 I can't use make with more than 1 job - build
freezes. On msysCORE-1.0.17 its ok.

Re: [Mingw-msys] MSYS using Junctions quirk

[dmccunney <den...@gm...>]

On Tue, Aug 28, 2012 at 4:07 PM, Earnie Boyd
<ea...@us...> wrote:
> On Tue, Aug 28, 2012 at 3:30 PM, dmccunney wrote:
>>
>> Which is why I want to be aware of issues.  Mysy mounts are one such:
>> it looks like I ought not to mix Msys tools with others.  The Gnuwin32
>> toolset looks like a reasonably good set of the standard command line
>> tools.  The fun part is a *nix like shell.  I started using Unix with
>> SysVR2 and am an old Korn shell guy, but if it uses the Bourne script
>> language and has decent interactive features like command line
>> editing, aliases, and functions, I can deal. This means bash, mksh,
>> and zsh are usable, but lets out tcsh for anything save occasional
>> use.  Back in the MS-DOS days, I used the MKS Toolkit, largely because
>> they *had* a good Korn shell port.
>
> Bash has decent emulation for standard Bourne shell syntax when named
> sh and has some ksh features.
> http://web.mit.edu/gnu/doc/html/features_3.html

Yep.  I use bash under Linux (and I'm up under Ubuntu 12.04 LTS at the
moment.)  The bash developers appeared to be trying to include
everything *including* the kitchen sink, and produced what you might
get if you merged sh, ksh, and csh in one shell.  In the process, it
got big and resource intensive enough that we got ash, with the shell
language but without the interactive stuff, specifically to run things
like install scripts with less overhead.  (I found one ancient
win-bash port based on bash 1.x, and the FAQ answer to "Why not a more
recent version" is "It runs the scripts we wanted to be able to run.")

AT&T made the real ksh open source, but their license isn't compatible
with things like the GPL, so Cygwin can't include it, and I haven't
seen a Windows version other than AT&T's UWin environment.

(Incompatible licenses are probably the biggest open source stumbling
block I can think of.)

> Earnie
> -- https://sites.google.com/site/earnieboyd
______
Dennis
https://plus.google.com/u/0/105128793974319004519

Re: [Mingw-msys] MSYS using Junctions quirk

[Earnie B. <ea...@us...>]

On Tue, Aug 28, 2012 at 3:30 PM, dmccunney wrote:
>
> Which is why I want to be aware of issues.  Mysy mounts are one such:
> it looks like I ought not to mix Msys tools with others.  The Gnuwin32
> toolset looks like a reasonably good set of the standard command line
> tools.  The fun part is a *nix like shell.  I started using Unix with
> SysVR2 and am an old Korn shell guy, but if it uses the Bourne script
> language and has decent interactive features like command line
> editing, aliases, and functions, I can deal. This means bash, mksh,
> and zsh are usable, but lets out tcsh for anything save occasional
> use.  Back in the MS-DOS days, I used the MKS Toolkit, largely because
> they *had* a good Korn shell port.
>

Bash has decent emulation for standard Bourne shell syntax when named
sh and has some ksh features.
http://web.mit.edu/gnu/doc/html/features_3.html

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-msys] MSYS using Junctions quirk

[dmccunney <den...@gm...>]

On Tue, Aug 28, 2012 at 2:53 PM, Earnie Boyd
<ea...@us...> wrote:
> On Tue, Aug 28, 2012 at 1:38 PM, dmccunney wrote:
>>
>>> The tcsh, etc shells, are they Cygwin related or something else?
>>
>> Something else.
>
> Ok, good.  There could be issue with mixing these environments.

Which is why I want to be aware of issues.  Mysy mounts are one such:
it looks like I ought not to mix Msys tools with others.  The Gnuwin32
toolset looks like a reasonably good set of the standard command line
tools.  The fun part is a *nix like shell.  I started using Unix with
SysVR2 and am an old Korn shell guy, but if it uses the Bourne script
language and has decent interactive features like command line
editing, aliases, and functions, I can deal. This means bash, mksh,
and zsh are usable, but lets out tcsh for anything save occasional
use.  Back in the MS-DOS days, I used the MKS Toolkit, largely because
they *had* a good Korn shell port.

>> There are lots of third-party ports of Unix tools to
>> Win32, like the Gnuwin32 offerings and Karl Syring's UnxUtils
>> (http://unxutils.sourceforge.net/UnxUtils.html)  Zsh is Syring's port,
>> though there are a couple of others,  Just poking around on
>> Sourceforge, I've seen a POSIX compatibility layer implemented as a
>> device by a Russian developer, and installed by Add/Remove Hardware,
>> and an offering called PW32 that looks like it's trying to do
>> something similar to Msys. (That one hasn't been updated in a while,
>> and appears moribund.)
>
> I'll caution you with some of these.  IIRC, Zsh contains a fork
> implementation based on Cygwin's fork and from what I remember isn't
> being updated recently.  The last update of unxutils was in 2007;
> pretty old but if it works, so be it.

The UnxUtils tools seem to work well enough.  I have a couple of
different versions of zsh, of which one is Syring's.  But they are
based on older versions of zsh, that don't support things like
--version, so it isn't terribly clear what zsh code they were based
on.  (I know,  Look at the source...)

> PW32 is pretty much dead.  The developer used to communicate with the
> MinGW team.

Since it hasn't been updated in some time, that was my assumption.  I
was fascinated it existed, but unsurprised it was moribund.  I've lost
count of the number of promising open source offerings I've seen that
withered because the devs lost interest/didn't have time/whatever, and
they never achieved enough traction to induce someone else to pick
them up.

>> Everyone seems to implement a different set of the tools, and a
>> background effort here is to get the fullest possible set, which means
>> mix and match, with preference given to the most recent version
>> ported,
>
> And everyone tends to have varying goals.  MSYS was started to provide
> a means for MinGW to execute a typical configure and make process for
> building native tools.

Yep, and it apparently does it well .  I just don't happen to be doing
that.  All I need is a decent set of the standard command line tools
used outside of the development process, and access to a *nix like
shell on occasion.

> Earnie
> -- https://sites.google.com/site/earnieboyd
______
Dennis
https://plus.google.com/u/0/105128793974319004519

Re: [Mingw-msys] MSYS using Junctions quirk

[Earnie B. <ea...@us...>]

On Tue, Aug 28, 2012 at 1:38 PM, dmccunney wrote:
>
>> The tcsh, etc shells, are they Cygwin related or something else?
>
> Something else.

Ok, good.  There could be issue with mixing these environments.

> There are lots of third-party ports of Unix tools to
> Win32, like the Gnuwin32 offerings and Karl Syring's UnxUtils
> (http://unxutils.sourceforge.net/UnxUtils.html)  Zsh is Syring's port,
> though there are a couple of others,  Just poking around on
> Sourceforge, I've seen a POSIX compatibility layer implemented as a
> device by a Russian developer, and installed by Add/Remove Hardware,
> and an offering called PW32 that looks like it's trying to do
> something similar to Msys. (That one hasn't been updated in a while,
> and appears moribund.)
>

I'll caution you with some of these.  IIRC, Zsh contains a fork
implementation based on Cygwin's fork and from what I remember isn't
being updated recently.  The last update of unxutils was in 2007;
pretty old but if it works, so be it.

PW32 is pretty much dead.  The developer used to communicate with the
MinGW team.

> Everyone seems to implement a different set of the tools, and a
> background effort here is to get the fullest possible set, which means
> mix and match, with preference given to the most recent version
> ported,

And everyone tends to have varying goals.  MSYS was started to provide
a means for MinGW to execute a typical configure and make process for
building native tools.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-msys] MSYS using Junctions quirk

[dmccunney <den...@gm...>]

On Tue, Aug 28, 2012 at 1:09 PM, Earnie Boyd
<ea...@us...> wrote:
> On Tue, Aug 28, 2012 at 11:49 AM, dmccunney wrote:
>>>> Right now, I have Msys mapped via a junction as /bin, and can live
>>>> with it.  But I'm curious: *should* creating the junction as /usr/bin
>>>> have worked, or am I running into an inherent limit in how Msys works,
>>>> or have I found a bug?
>>>
>>> Why?  When you start the MSYS shell it maps itself already to / and
>>> /usr.  What are you trying to accomplish?
>>
>> Like I said, a Unix style file system arrangement.  *Msys* may map
>> itself to / and /usr, but I'm not always *in* the Msys shell when I''m
>> in a console.  Aside from Msys bash, I have versions of tcsh, zsh, and
>> ksh, as well as Windows cmd.exe.  They don't see the Msys mapping.  (I
>> use Console2  to get a tabbed console window, and may have more than
>> one shell active at a time.)
>
> So the issue becomes this, for MSYS it maps / and /usr to the parent
> of the directory containing the msys-1.0.dll and the directory
> containing msys-1.0.dll becomes /bin and /usr/bin.  When you create
> the junction c:/usr/bin to the msys/1.0/bin and execute from
> c:/usr/bin then root / is then mapped to c:/usr and MSYS is all
> confused.

And that confusion accounts for the fact that the various mys tools
simply silently fail when executed from /usr/bin.  (I assume they set
a non-zero exit status of some kind.)  Okay.  That explains what's
going on.

I have Cygwin as well (though not currently used on the notebook,) but
I'd prefer to avoid the quirks involved in trying to use such tools
from outside their native environment.  I want to have such tools in
my Windows PATH, execute them from CMD.EXE as well as whatever their
native shell might be, and expect reasonable results.  Like I said,
I'm not trying to do development on the box, so GCC and the like are
irrelevant.  I just want to do things like type ls -l at a prompt, get
a long form ls listing, and not care about just which prompt I'm doing
it from.

> The tcsh, etc shells, are they Cygwin related or something else?

Something else.  There are lots of third-party ports of Unix tools to
Win32, like the Gnuwin32 offerings and Karl Syring's UnxUtils
(http://unxutils.sourceforge.net/UnxUtils.html)  Zsh is Syring's port,
though there are a couple of others,  Just poking around on
Sourceforge, I've seen a POSIX compatibility layer implemented as a
device by a Russian developer, and installed by Add/Remove Hardware,
and an offering called PW32 that looks like it's trying to do
something similar to Msys. (That one hasn't been updated in a while,
and appears moribund.)

Everyone seems to implement a different set of the tools, and a
background effort here is to get the fullest possible set, which means
mix and match, with preference given to the most recent version
ported,

> Earnie
> -- https://sites.google.com/site/earnieboyd
______
Dennis
https://plus.google.com/u/0/105128793974319004519

Re: [Mingw-msys] MSYS using Junctions quirk

[Earnie B. <ea...@us...>]

On Tue, Aug 28, 2012 at 11:49 AM, dmccunney wrote:
>>> Right now, I have Msys mapped via a junction as /bin, and can live
>>> with it.  But I'm curious: *should* creating the junction as /usr/bin
>>> have worked, or am I running into an inherent limit in how Msys works,
>>> or have I found a bug?
>>
>> Why?  When you start the MSYS shell it maps itself already to / and
>> /usr.  What are you trying to accomplish?
>
> Like I said, a Unix style file system arrangement.  *Msys* may map
> itself to / and /usr, but I'm not always *in* the Msys shell when I''m
> in a console.  Aside from Msys bash, I have versions of tcsh, zsh, and
> ksh, as well as Windows cmd.exe.  They don't see the Msys mapping.  (I
> use Console2 to get a tabbed console window, and may have more than
> one shell active at a time.)

So the issue becomes this, for MSYS it maps / and /usr to the parent
of the directory containing the msys-1.0.dll and the directory
containing msys-1.0.dll becomes /bin and /usr/bin.  When you create
the junction c:/usr/bin to the msys/1.0/bin and execute from
c:/usr/bin then root / is then mapped to c:/usr and MSYS is all
confused.

The tcsh, etc shells, are the Cygwin related or something else?

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-msys] MSYS using Junctions quirk

[dmccunney <den...@gm...>]

On Tue, Aug 28, 2012 at 8:12 AM, Earnie Boyd
<ea...@us...> wrote:
> On Mon, Aug 27, 2012 at 6:12 PM, dmccunney wrote:
>> I'm not sure whether I'm encountering a bug or just getting bitten by
>> lack of knowledge.
>
> The latter is what I'm thinking.  BTW, support for MSYS happens on
> mingw-user, the documentation needs changed.

So noted. Thanks.

>> Right now, I have Msys mapped via a junction as /bin, and can live
>> with it.  But I'm curious: *should* creating the junction as /usr/bin
>> have worked, or am I running into an inherent limit in how Msys works,
>> or have I found a bug?
>
> Why?  When you start the MSYS shell it maps itself already to / and
> /usr.  What are you trying to accomplish?

Like I said, a Unix style file system arrangement.  *Msys* may map
itself to / and /usr, but I'm not always *in* the Msys shell when I''m
in a console.  Aside from Msys bash, I have versions of tcsh, zsh, and
ksh, as well as Windows cmd.exe.  They don't see the Msys mapping.  (I
use Console2 to get a tabbed console window, and may have more than
one shell active at a time.)

>> * And too my surprise, a recent update to LSE pointed to an open
>> source driver written by a Japanese developer that enables true
>> symlinks in 2K and XP.  NTFS5 has the underlying infrastructure to
>> support symlinks, but it's not exposed by the 2k/XP kernel.  The
>> driver amends that oversite.
>
> MSYS when I forked Cygwin to develop it did not have a Windows
> junction or a Windows symlink to rely on and the way Cygwin had
> emulated it did not work for a native application.  Therefore it was
> removed and the functions return ENOSYS error.

I assumed something like that.  Native support now exists (for
Vista/Win7, at least.)  Any plans to add it to Msys?

> Earnie
> -- https://sites.google.com/site/earnieboyd
______
Dennis
https://plus.google.com/u/0/105128793974319004519