Menu
▾
▴
mingw-users
|
From: Peter <one...@ya...> - 2010-09-12 20:51:45
|
Hi,
I just downloaded the latest msys package.
If I have a directory name or file name in non-English character,
ls.exe cannot display it correctly. all of characters displayed as ?????.
if I have a file 01.txt contains non-English characters,
cat.exe works fine and can display correctly. However, less.exe doesn't work and will prompt:
"01.txt" may be a binary file. See it anyway?
it doens't display correctly after I typed "yes".
if cat.exe can work correctly, not sure how hard to get ls.exe and less.exe to work right?
thanks.
Peter
|
|
From: Tor L. <tm...@ik...> - 2010-09-13 00:03:39
|
> if cat.exe can work correctly, not sure how hard to get ls.exe and less.exe to work right? Displaying file names and file contents are not related at all. And cat is much simpler than less. --tml |
|
From: Peter <one...@ya...> - 2010-09-13 00:43:34
|
--- On Sun, 9/12/10, Tor Lillqvist <tm...@ik...> wrote:
> From: Tor Lillqvist <tm...@ik...>
> Subject: Re: [Mingw-users] msys localization display issues for ls.exe and less.exe
> To: "MinGW Users List" <min...@li...>
> Date: Sunday, September 12, 2010, 5:03 PM
> > if cat.exe can work correctly,
> not sure how hard to get ls.exe and less.exe to work
> right?
>
> Displaying file names and file contents are not related at
> all. And
> cat is much simpler than less.
I agree with you.
is it too difficult to implement such a feature?
or the problem is first reported here?
Thanks.
Peter
|
|
From: Tor L. <tm...@ik...> - 2010-09-13 06:30:56
|
> is it too difficult to implement such a feature?
Perhaps not, but nobody has felt it important enough to bother?
Making utilities like ls display non-ASCII file names correctly would
be slightly useful, but it is in no way essential, IMHO.
(And I say that as somebody whose native language is not English, and
who always uses the local keyboard layout, not en-US one, even if that
means accessing keys like \ { [ ] } is behind AltGr.)
You should consider what is the intended purpose of MSYS: running
configure and other software build scripts, Makefiles etc. And also
provide a familiar Unix-style interactive *software development
environment*. Mainly, perhaps, for software being ported from Unix,
and especially for developing and porting Open Source software to
Windows. Do you know many software packages (Open Source or
proprietary) that would use non-ASCII source file name?
If you are on Windows and handle lots of files with non-ASCII names,
you most likely are handling end-user documents, not developing
software. Then MSYS is perhaps not the right tool for you.
Have you tried Microsoft's SUA (a.k.a. Interix), does it handle
non-ASCII file names better? Or Cygwin, I know they did some
significant changes for UTF8ification of Cygwin in version 1.7.
--tml
|
|
From: Peter <one...@ya...> - 2010-09-14 04:54:26
|
--- On Sun, 9/12/10, Tor Lillqvist <tm...@ik...> wrote: > From: Tor Lillqvist <tm...@ik...> > Subject: Re: [Mingw-users] msys localization display issues for ls.exe and less.exe > To: "MinGW Users List" <min...@li...> > Date: Sunday, September 12, 2010, 11:30 PM > > is it too difficult to implement > such a feature? > > Perhaps not, but nobody has felt it important enough to > bother? OK. I just report what I see the problem. it is up to the core developer to make a decision to fix or ignore. > If you are on Windows and handle lots of files with > non-ASCII names, > you most likely are handling end-user documents, not > developing > software. Then MSYS is perhaps not the right tool for you. that is not true. it means that grep and cp, or mv cannot handle all non-english files correctly. I just noticed that ls.exe from gnuwin32.sourceforge.net can display non-English file names and directory correctly. less.exe from gnuwin32 can also display non-English content correctly. is it because msys used different source code for compilation? or is it because of compiler related issue? Microsoft interix or cygwin is too heavy for me. thanks. Peter |
|
From: Charles W. <cwi...@us...> - 2010-09-14 05:06:36
|
On 9/14/2010 12:54 AM, Peter wrote: > Microsoft interix or cygwin is too heavy for me You do realize that MSYS *is* cygwin, right? It is a fork of cygwin from about 2003... The issue is, something in the core runtime needs to provide support for wide characters. In the case of GnuWin32 tools, they have heavily patched the source of all clients (less, grep, etc) to use the wide char stuff provided by *Microsoft's* runtime libraries. In the case of cygwin, they have (recently) made MAJOR changes in the cygwin1.dll runtime to support wide characters. Old cygwin -- that is, MSYS -- does not have that support. So, for "msys" clients there are really only two choices: (a) either msys makes similar *massive* changes -- which took the cygwin folks over 18 months to finalize -- or (b) the clients themselves bypass msys and use the Microsoft runtime support directly. But then, they wouldn't actually *be* msys applications anymore; they'd be, in effect, GnuWin32 apps. Since I don't see (a) happening anytime soon (the most likely course of affairs is a "reboot" of msys-2.0, re-forking from cygwin-NOW rather than cygwin-2003; odds of that happening in the next 24 months: < 5%), AND since GnuWin apps work perfectly well from an MSYS shell, my suggestion to you is: install all the tools from GnuWin32 you like, mount them via msys's /etc/fstab under /gnuwin, and put /gunwin/bin in your path before /bin. -- Chuck |
|
From: Andy K. <and...@gm...> - 2010-09-14 05:56:47
|
On 14 September 2010 06:05, Charles Wilson wrote: > On 9/14/2010 12:54 AM, Peter wrote: >> Microsoft interix or cygwin is too heavy for me > > You do realize that MSYS *is* cygwin, right? It is a fork of cygwin > from about 2003... > > The issue is, something in the core runtime needs to provide support for > wide characters. In the case of GnuWin32 tools, they have heavily > patched the source of all clients (less, grep, etc) to use the wide char > stuff provided by *Microsoft's* runtime libraries. In the case of > cygwin, they have (recently) made MAJOR changes in the cygwin1.dll > runtime to support wide characters. > > Old cygwin -- that is, MSYS -- does not have that support. So, for > "msys" clients there are really only two choices: (a) either msys makes > similar *massive* changes -- which took the cygwin folks over 18 months > to finalize -- or (b) the clients themselves bypass msys and use the > Microsoft runtime support directly. But then, they wouldn't actually > *be* msys applications anymore; they'd be, in effect, GnuWin32 apps. > > Since I don't see (a) happening anytime soon (the most likely course of > affairs is a "reboot" of msys-2.0, re-forking from cygwin-NOW rather > than cygwin-2003 ... and hopefully maintaining it as a patchset rather than an outright fork, so the same situation doesn't arise again later. Andy |
|
From: Charles W. <cwi...@us...> - 2010-09-14 16:45:32
|
On 9/14/2010 1:56 AM, Andy Koppe wrote: > On 14 September 2010 06:05, Charles Wilson wrote: >> Since I don't see (a) happening anytime soon (the most likely course of >> affairs is a "reboot" of msys-2.0, re-forking from cygwin-NOW rather >> than cygwin-2003 > > ... and hopefully maintaining it as a patchset rather than an outright > fork, so the same situation doesn't arise again later. That would be ideal, yes. IIRC, there were seven major differences (and probably a lot of minor differences) between cygwin-2003 and the original MSYS fork: 1) encoding of the $GLOBAL namespace object names so that multiple "MSYS" installations could coexist (*) -- although applications in one MSYS instance could not communicate with apps in a different MSYS instance. Contemporaneous cygwin allowed all cygwin apps in any instance to communicate with each other -- but if there were version mismatches between those cygwin instances...boom! (*) not to mention so that an msys installation could coexist with a "real" cygwin one. 2) automatic detection of the installation root, and the use of /etc/fstab (where C:\dos\path\to\etc was part of that autodetection) to implement the mount table. Contemporaneous cygwin used the registry for this purpose, including explicit specification of the installation root. 3) automatic mounting of attached hard drives, as C: -> /c, D: -> /d, etc. Contemporaneous cygwin auto-mounted hard drives as /cygdrive/c, /cygdrive/d, etc. 4) magic path translation and heuristics when calling exec() or spawn() with a "native" application. 5) uname(2) returned either MINGW32-blah-blah or MSYS-blah-blah, depending on the value of the environment variable $MSYSTEM. Also, lots of mechanical CYGWIN -> MSYS changes. 6) Very simple permissions modeling: chmod(2)/chown(2) have practically no effect. No real use of /etc/passwd or /etc/group. umask(2) does nothing. New files created with Full Control access for Everybody. Msys-stat() and access() queries basically return 666 for all files, and 777 for all ".exe's" and directories -- unless the DOS "Read Only" attribute was set. 7) symlink(2) implementation modified http://www.opengroup.org/onlinepubs/009695399/functions/symlink.html so that "file" symlinks were implemented as hardlinks if on the same device, and copies otherwise; "directory" symlinks implemented as recursive copies (with files "below" the directory treated as individual link(2): hardlink if on same device, copies otherwise). As it happens, modern cygwin versions now do #1: http://cygwin.com/ml/cygwin-announce/2009-11/msg00000.html by default (to get "old" cygwin behavior, you have to run 'cygcheck --disable-unique-object-names') and #2: http://www.cygwin.com/cygwin-ug-net/using.html#mount-table although the format of cygwin-1.7's fstab and msys's fstab are quite different. Also, #3 is easily implemented, by adding the following to /etc/fstab (or #ifdef'ing in a different default cygdrive prefix, for MSYS): none / cygdrive binary 0 0 #4 effects are localized to only two or three .cpp files #5 affects a single .cpp file #6 ... I dunno, this one is probably pretty pervasive. cygwin-1.7 made a LOT of changes in the permissions and ownership handling, so it might be difficult to "turn it off" in all the places it needs to be. #7 Again, only affects one or two .cpp files Then, there are the all the "new things" introduced in cygwin since 2003; some of which may be fine as they are, but others may need to be modified in some way for better "MSYS-ness". Stuff like exactly HOW i18n and wide chars are supported in new cygwin, especially with regards to path-names. Even cygwin has not yet nailed all of this down yet; they are currently trying to figure out the best way to handle REALLY long file names (>4K, up to 32K chars). cygwin-1.7 has no problems with them, but there IS a problem if a cygwin program (say, bash) calls a win32 API function while the current working directory is set to a really long path -- because the win32 subsystem itself doesn't really support them. One such problematic win32 api function is CreateProcess (which, unfortunately, is called under-the-hood by exec() and spawn() when the target is a native app)! This is an even bigger issue for MSYS than for cygwin, because while you are "in" cygwin it is possible you might almost ALWAYS launch only other cygwin apps. But, the whole POINT of MSYS is to launch *native* apps -- like MinGW gcc -- via a unix-like shell (which uses fork/exec() semantics to launch commands). Thus, an MSYS bash is *often* used to launch a native app (ultimately) via CreateProcess. If new-MSYS supports really long paths, then you will have problems if CWD is a really-long-path, and you try to run MinGW gcc... So, in some ways forking msys-2.0 from current cygwin will be easier to maintain, because many of the most intrusive *existing* differences are no longer needed. But in other ways, it may be just as difficult as before, because we aren't yet sure how the new cygwin capabilities should be "translated" for a smooth "MSYS"-like experience. Alternatively, we could take a long, hard look at some of the decisions made in the early MSYS days, and consider if, in this new era of somewhat improved native win32 security (**), whether we need ALL of these differences from cygwin? Maybe #4, #5, and #7 are all we *really* need anymore? (**) That is, all current versions of windows are now based on the NT kernel, and support some modicum of security; back in the old days we still had to worry about win9x and its zero-security model. New-cygwin no longer supports win9x at all (and neither does microsoft); should we worry about it any longer, for msys-2.0?) The downside here is that you would no longer be able to use any-old-win32 tool to "unpack" msys packages, because the unpacker would have to "know" how to set the correct ACLs on the unpacked files; kinda like cygwin's setup.exe does. However, we still want to be able to use any-old-unpacker for the MinGW packages...so msys itself would need to be able to "deal" with that... In any case, I really do think it would be easier to maintain any such msys-2.0 using a git mirror of cygwin's repo, and putting msys on a git branch. That way, merges from "upstream" would be a lot simpler; branches are SO much easier to work with in git... But, to even THINK about that, *we* need to distribute an actual msys port of git (and not rely *directly* on the msysgit version, which IIUC is actually a MinGW version bundled *with* msys). And that needs, I *think*, a newer perl implementation than 5.6.1... (not sure why, but msysgit went thru the effort of porting 5.8.8 for SOME reason.) And higher priority than ANY of that, is to get mingw-get (CUI) support for package removal and package upgrades, instead of the current install-only behavior. And then some sort of "real" GUI, instead of the goofy InnoSetup "wrapper" we have right now. Sigh. One thing at a time... -- Chuck |
|
From: Tor L. <tm...@ik...> - 2010-09-14 18:38:24
|
> Alternatively, we could take a long, hard look at some of the decisions > made in the early MSYS days, and consider if, in this new era of > somewhat improved native win32 security (**), whether we need ALL of > these differences from cygwin? Uhm, personally I find Cygwin's desperate attempts to implement POSIX protection semantics using various hacks on the Windows ACLs less than reliable. In scenarios where you mix Cygwin and non-Cygwin tools (the latter including Explorer) (which kind of situation of course is what MSYS is for) to manipulate the same directories and files, you easily get into strange situations. (If you use only Cygwin to look at and manipulate some tree, sure, it probably works as intended.) If a fresh MSYS2 effort would be forked off a current Cygwin, IMHO it should again definitely this time, too, drop the attempts to emulate POSIX protection. (And in any case, obviously it would be better to not "fork" as such, but just add clean conditional code to the upstream codebase.) (But note that I don't see any urgent need for such a fresh MSYS2 effort... at least not for the reasons that started this thread.) --tml |
|
From: Earnie <ea...@us...> - 2010-09-16 12:07:31
|
Charles Wilson wrote: > > #6 ... I dunno, this one is probably pretty pervasive. cygwin-1.7 made a > LOT of changes in the permissions and ownership handling, so it might be > difficult to "turn it off" in all the places it needs to be. > > #7 Again, only affects one or two .cpp files > > > > Then, there are the all the "new things" introduced in cygwin since > 2003; some of which may be fine as they are, but others may need to be > modified in some way for better "MSYS-ness". Stuff like exactly HOW > i18n and wide chars are supported in new cygwin, especially with regards > to path-names. Even cygwin has not yet nailed all of this down yet; > they are currently trying to figure out the best way to handle REALLY > long file names (>4K, up to 32K chars). > I started once upon a time some long time ago to make a msys-2 that would be able to keep up with the jones' as they changed their house. But I soon realized it was an act that was leading to futility. There are changes that just don't fit like the insistence on /etc/passwd and /etc/group files. I think the better solution is to maintain the current fork and improve it to work as we need it to. > > Alternatively, we could take a long, hard look at some of the decisions > made in the early MSYS days, and consider if, in this new era of > somewhat improved native win32 security (**), whether we need ALL of > these differences from cygwin? Maybe #4, #5, and #7 are all we *really* > need anymore? > I champion any changes that Cygwin makes that is anywhere near similar to the changes I made in MSYS just for this reason. However, things like /etc/passwd and /etc/group are some of the changes that would make it difficult to deal with, IMO. > (**) That is, all current versions of windows are now based on the NT > kernel, and support some modicum of security; back in the old days we > still had to worry about win9x and its zero-security model. New-cygwin > no longer supports win9x at all (and neither does microsoft); should we > worry about it any longer, for msys-2.0?) The downside here is that you > would no longer be able to use any-old-win32 tool to "unpack" msys > packages, because the unpacker would have to "know" how to set the > correct ACLs on the unpacked files; kinda like cygwin's setup.exe does. > However, we still want to be able to use any-old-unpacker for the MinGW > packages...so msys itself would need to be able to "deal" with that... > I think w9x is still used in too many places to dump it wholly as much as I would like to. > > > In any case, I really do think it would be easier to maintain any such > msys-2.0 using a git mirror of cygwin's repo, and putting msys on a git > branch. That way, merges from "upstream" would be a lot simpler; > branches are SO much easier to work with in git... > A git repository may just be the ticket even for a MSYS-2 of the existing fork. > But, to even THINK about that, *we* need to distribute an actual msys > port of git (and not rely *directly* on the msysgit version, which IIUC > is actually a MinGW version bundled *with* msys). And that needs, I > *think*, a newer perl implementation than 5.6.1... (not sure why, but > msysgit went thru the effort of porting 5.8.8 for SOME reason.) > I moved the git binaries to my MinGW/MSYS setup and successfully used it. I am reviewing the patches msysgit made to MSYS and will be in discussion with that group of developers on why some of the changes were made. Some are just intuitive and will go in without much problem. One change will affect RXVT because it gets rid of tty but I have seen no problems with the git client and the lack of changes to MSYS. > And higher priority than ANY of that, is to get mingw-get (CUI) support > for package removal and package upgrades, instead of the current > install-only behavior. And then some sort of "real" GUI, instead of the > goofy InnoSetup "wrapper" we have right now. > Definitely. One change you didn't mention is that MSYS sets CYGWIN options without letting the user make a change to the chosen option. This was done for the ease of maintenance when a user was complaining about something not working. I didn't have to know what the option settings were because they were hard coded and made testing 1000's of times easier. -- Earnie -- http://www.for-my-kids.com |
|
From: Andy K. <and...@gm...> - 2010-09-17 05:29:56
|
On 16 September 2010 13:07, Earnie wrote: > I am reviewing the patches msysgit made to MSYS and will be in > discussion with that group of developers on why some of the changes were > made. Some are just intuitive and will go in without much problem. One > change will affect RXVT because it gets rid of tty Can you elaborate on that one? (I assume mintty would be affected too.) Andy |
|
From: Earnie <ea...@us...> - 2010-09-17 11:38:14
|
Andy Koppe wrote: > On 16 September 2010 13:07, Earnie wrote: >> I am reviewing the patches msysgit made to MSYS and will be in >> discussion with that group of developers on why some of the changes were >> made. Some are just intuitive and will go in without much problem. One >> change will affect RXVT because it gets rid of tty > > Can you elaborate on that one? (I assume mintty would be affected too.) > http://repo.or.cz/w/msysgit.git/blob/msys:/src/rt/patches/0006-Ignore-the-tty-option-from-the-CYGWIN-environment-va.patch I don't know that this should make it, lots of testing needs to take place to determine affects. -- Earnie -- http://www.for-my-kids.com |
|
From: Andy K. <and...@gm...> - 2010-09-17 12:12:26
|
On 17 September 2010 12:38, Earnie wrote: > Andy Koppe wrote: >> On 16 September 2010 13:07, Earnie wrote: >>> I am reviewing the patches msysgit made to MSYS and will be in >>> discussion with that group of developers on why some of the changes were >>> made. Some are just intuitive and will go in without much problem. One >>> change will affect RXVT because it gets rid of tty >> >> Can you elaborate on that one? (I assume mintty would be affected too.) >> > > http://repo.or.cz/w/msysgit.git/blob/msys:/src/rt/patches/0006-Ignore-the-tty-option-from-the-CYGWIN-environment-va.patch "There is no working pty emulation in MSys, so it makes no sense to allow asking for that emulation. The symptoms are non-working vi, looping ssh questions to accept host keys or passwords." That's quite wrong. MSYS's pty emulation works fine. Rxvt and mintty both use it. (It's a lot slower than Cygwin's latest, but that's another matter.) Rxvt and mintty don't actually care about CYGWIN=tty though, because the setting only affects MSYS programs invoked in a console window, where it enables the pipe-based pty emulation instead of connecting the standard streams directly to the console window. As far as I can see, that's working fine too, e.g. it enables suspending of processes with ^Z, and MSYS vim and ssh look perfectly happy with it. I guess what the comment is referring to is running non-MSYS programs in a pty session. As Chuck and I know only too well, interactive console programs often don't work properly when they're talking to the pair of pipes that the pty emulation is based on instead of being connected directly to a console device. Andy |
|
From: Earnie <ea...@us...> - 2010-09-17 12:37:43
|
Andy Koppe wrote: > > I guess what the comment is referring to is running non-MSYS programs > in a pty session. As Chuck and I know only too well, interactive > console programs often don't work properly when they're talking to the > pair of pipes that the pty emulation is based on instead of being > connected directly to a console device. > Yes I think this is the issue trying to be resolved. But I use native git in my own MSYS environment, not the modified one without issue. -- Earnie -- http://www.for-my-kids.com |
|
From: Andy K. <and...@gm...> - 2010-09-18 05:16:36
|
On 17 September 2010 13:37, Earnie wrote: > Andy Koppe wrote: >> >> I guess what the comment is referring to is running non-MSYS programs >> in a pty session. As Chuck and I know only too well, interactive >> console programs often don't work properly when they're talking to the >> pair of pipes that the pty emulation is based on instead of being >> connected directly to a console device. > > Yes I think this is the issue trying to be resolved. But I use native > git in my own MSYS environment, not the modified one without issue. I found it rather surprising that the 'git' in msysgit isn't actually an MSYS program. Anyway, as far as mintty is concerned, I don't mind if the CYGWIN=tty setting were to disappear. In fact I'd recommend mintty to anyone who is using that setting (although I doubt there are many). It shares the issue above, but offers a nicer user interface and more standards-compliant terminal emulation than the console, which makes it particularly suited to MSYS programs and remote connections to Unix/Linux machines. Andy |
|
From: K. H. <los...@zi...> - 2010-09-20 22:18:09
|
On 9/17/2010 11:16 PM, Andy Koppe wrote: > I found it rather surprising that the 'git' in msysgit isn't actually > an MSYS program. > The reason for using msys with a native git is that their are four types of git commands: C code, sh scripts, perl, and tcl/tk. |
|
From: Charles W. <cwi...@us...> - 2010-09-20 22:51:13
|
On 9/20/2010 5:51 PM, K. Haley wrote: > On 9/17/2010 11:16 PM, Andy Koppe wrote: >> I found it rather surprising that the 'git' in msysgit isn't actually >> an MSYS program. >> > The reason for using msys with a native git is that their are four types > of git commands: C code, sh scripts, perl, and tcl/tk. So...no msys port of tcl/tk, is that it? (and, by default, an msys-ish build of tcl/tk would require msys-X11 libs, which don't exist; you'd really need to replicate the frankenstein cygwin tcl/tk patches which create a hybrid tcl/tk that uses C:/dos/paths and GDI windowing, but is a cygwin [ne' msys] app). I realize git has a lot of additional deps (presently not satisfied in msys: libidn, libssh2, libcurl) so that makes things hard -- but not impossible. Also, python(!) but that might be optional; I'm not sure. -- Chuck |
|
From: Earnie <ea...@us...> - 2010-09-21 11:25:15
|
Charles Wilson wrote: > On 9/20/2010 5:51 PM, K. Haley wrote: >> On 9/17/2010 11:16 PM, Andy Koppe wrote: >>> I found it rather surprising that the 'git' in msysgit isn't actually >>> an MSYS program. >>> >> The reason for using msys with a native git is that their are four types >> of git commands: C code, sh scripts, perl, and tcl/tk. > > So...no msys port of tcl/tk, is that it? (and, by default, an msys-ish > build of tcl/tk would require msys-X11 libs, which don't exist; you'd > really need to replicate the frankenstein cygwin tcl/tk patches which > create a hybrid tcl/tk that uses C:/dos/paths and GDI windowing, but is > a cygwin [ne' msys] app). > > I realize git has a lot of additional deps (presently not satisfied in > msys: libidn, libssh2, libcurl) so that makes things hard -- but not > impossible. Also, python(!) but that might be optional; I'm not sure. > I think the native tcl/tk should work for git. The git binaries themselves are native. The use of MSYS in git is for bash shell scripting mostly. The tcl/tk that git uses is for a GUI presentation wrapper. -- Earnie -- http://www.for-my-kids.com |
|
From: Charles W. <cwi...@us...> - 2010-09-21 13:00:13
|
On 9/21/2010 7:25 AM, Earnie wrote: > I think the native tcl/tk should work for git. The git binaries > themselves are native. Sure, native tcl/tk for native git. msys-tcl/tk for msys git. We're discussing WHY the msysgit team chose to bundle a native git with a bunch of msys atmospherics -- as opposed to porting git itself to msys. In the message to which you replied, I was positing the supposition that the reason was, the lack of a modern msys tcl/tk, and the associated difficulties with creating one (along with the other prereqs), meant that it was easier for the msysgit team to just provide a native git instead, with additional msys "stuff" wrapped around it, to support bash shell scripting etc, as you say. > The use of MSYS in git is for bash shell > scripting mostly. The tcl/tk that git uses is for a GUI presentation > wrapper. You're talking about what IS, in the current "msysgit" project. I'm talking about what COULD BE, in something mingw.org ports/ships/creates. I can't help but think that an actual msys port of git would integrate more cleanly into the MSYS environment (why not just use native cvs rather than an msys port? ssh?) -- Chuck |
|
From: Earnie <ea...@us...> - 2010-09-21 23:31:27
|
Charles Wilson wrote: > > You're talking about what IS, in the current "msysgit" project. I'm > talking about what COULD BE, in something mingw.org > ports/ships/creates. > Ok, sorry, ignore me. ;) > I can't help but think that an actual msys port of git would > integrate more cleanly into the MSYS environment (why not just use > native cvs rather than an msys port? ssh?) > Well, that is a good question. The mingw port code is interesting and I might be inclined to agree with you. http://repo.or.cz/w/git/mingw/4msysgit.git/blob/22c0a2ff4e5795a90676eba658a5c45cafc6b851:/compat/mingw.c#l1021 and http://repo.or.cz/w/git/mingw/4msysgit.git/blob/22c0a2ff4e5795a90676eba658a5c45cafc6b851:/compat/mingw.c#l1049 -- Earnie -- http://www.for-my-kids.com |
|
From: Ladislav M. <la...@li...> - 2010-09-16 18:48:26
|
On Tue, Sep 14, 2010 at 12:45:21PM -0400, Charles Wilson wrote: > So, in some ways forking msys-2.0 from current cygwin will be easier to > maintain, because many of the most intrusive *existing* differences are > no longer needed. But in other ways, it may be just as difficult as > before, because we aren't yet sure how the new cygwin capabilities > should be "translated" for a smooth "MSYS"-like experience. I spent couple (well, more that 30) of hours last week figuring Cygwin/MSYS differences and found impossible to rebase MSYS fork to more recent version of Cygwin in finite time. Well, it's impossible as one man show, but... It was done as an excercise while trying to rewrite path_conv class to support native symlinks, see http://sourceforge.net/tracker/?func=detail&aid=3046195&group_id=2435&atid=302435 It turned out that at least in this case MSYS differences can be "easily" (*) hidden in MSYS specific class implementations, preferably using common ancestor class for both Cygwin and MSYS. (*) Well, that needs a lot of will on Cygwin side, as it gives almost nothing to them. So while technically quite nice solution, it is unlikely to be implemented. > One thing at a time... Yup :-) ladis |
|
From: Charles W. <cwi...@us...> - 2010-09-14 19:29:15
|
On 9/14/2010 2:37 PM, Tor Lillqvist wrote: >> Alternatively, we could take a long, hard look at some of the decisions >> made in the early MSYS days, and consider if, in this new era of >> somewhat improved native win32 security (**), whether we need ALL of >> these differences from cygwin? > > Uhm, personally I find Cygwin's desperate attempts to implement POSIX > protection semantics using various hacks on the Windows ACLs less than > reliable. In scenarios where you mix Cygwin and non-Cygwin tools (the > latter including Explorer) (which kind of situation of course is what > MSYS is for) to manipulate the same directories and files, you easily > get into strange situations. Yes, I think this is correct. > (If you use only Cygwin to look at and > manipulate some tree, sure, it probably works as intended.) This part, too. As long as you stay seated in the cygwin comfy chair, stuff generally seems to work as intended. So: you get all the linuxy goodness as long as you ONLY use linuxy goodness. Now, you CAN interact with native apps...but sometimes there are rough edges. > If a fresh MSYS2 effort would be forked off a current Cygwin, IMHO it > should again definitely this time, too, drop the attempts to emulate > POSIX protection. (And in any case, obviously it would be better to > not "fork" as such, but just add clean conditional code to the > upstream codebase.) Well, it's been made pretty clear that upstream cygwin has ZERO interest in making it easy to disable anything that makes cygwin cygwin. Like POSIX file access controls. The closest you can come, upstream, is to force all mounts to be "noacl"...but that doesn't really have the effect MSYS would want (it is, literally, no acl IIRC; we'd want "implement wide-open ACLs on all files", I think). I'm afraid we're stuck with a fork; the question is, how divergent must that fork BE, in order to achieve the semantics appropriate for MSYS? > (But note that I don't see any urgent need for such a fresh MSYS2 > effort... at least not for the reasons that started this thread.) Oh, definitely agreed. The only real reason to refresh IMO is, cygwin has a moderately larger developer base, and their kernel has undergone continual bugfix/development for over six years. MSYS development has been rather less active...so cygwin, in addition to adding new features (*), has fixed a lot of bugs. Which we haven't. Worse, given the many underlying architectural changes, we can't even take their bugfixes...because our base code is so divergent after so long. For instance, we simply CAN'T build an msys-gcc based on gcc-4.x, because to do so requires a number of kernel level fixes in the msys dll itself (this has no bearing on *mingw* gcc, of course). (*) "real" support for wide chars and i18n in msys progs would surely be nice...OTOH, cygwin's use of reserved unicode chars to represent chars that are 'illegal' in win32 filenames is one of those "strange situations" you mentioned. Short version, I am in NO hurry to attempt this... -- Chuck |
|
From: Andy K. <and...@gm...> - 2010-09-14 20:22:12
|
On 14 September 2010 20:29, Charles Wilson wrote: > Well, it's been made pretty clear that upstream cygwin has ZERO interest > in making it easy to disable anything that makes cygwin cygwin. Like > POSIX file access controls. > > The closest you can come, upstream, is to force all mounts to be > "noacl"...but that doesn't really have the effect MSYS would want (it > is, literally, no acl IIRC; It don't think it means that ACLs are cleared or anything like that, it just means that Cygwin doesn't interpret or create ACLs. >From the manual: noacl - Cygwin ignores filesystem ACLs and only fakes a subset of permission bits based on the DOS readonly attribute Also: "While normally the execute permission bits are used to evaluate executability, this is not possible on filesystems which don't support permissions at all (like FAT/FAT32), or if ACLs are ignored on filesystems supporting them (see the aforementioned acl mount option). In these cases, the following heuristic is used to evaluate if a file is executable: Files ending in certain extensions (.exe, .com, .bat, .btm, .cmd) are assumed to be executable. Files whose first two characters begin with '#!' are also considered to be executable." I presume the ACLs on newly created files/directories are simply inherited from their parents. > we'd want "implement wide-open ACLs on all files", I think That doesn't sound right. In fact MSYS appears to implement the same approach described above, with the w bit being mapped to the readonly attribute and the x bit being faked: $ touch bla.txt $ ls -l bla.txt -rw-r--r-- 1 Andy Administrators 0 Sep 14 20:57 bla.txt $ chmod u+x bla.txt $ ls -l bla.txt -rw-r--r-- 1 Andy Administrators 0 Sep 14 20:57 bla.txt $ echo '#!' >bla.txt $ ls -l bla.txt -rwxr-xr-x 1 Andy Administrators 3 Sep 14 20:57 bla.txt Hence it seems #6 on your impressive writeup could be ticked off fairly easily as well. Also, #7 (symlinks) is partially there, because Cygwin does read Windows' various attempts at symlinks; it just doesn't create them because they don't behave posixly correctly in certain situations, hence Cygwin uses text files with special attributes instead. > there IS a problem if a cygwin > program (say, bash) calls a win32 API function while the current working > directory is set to a really long path -- because the win32 subsystem > itself doesn't really support them. Long path means >MAX_PATH (258 chars) here, which is supported by NT APIs and many, but unfortunately not all, Win32 APIs. Nothing anyone except MS can do about that, unless you'd want to keep MSYS paths restricted to MAX_PATH, which wouldn't really gain anything but cause additional failures in situations that might otherwise have worked. Aren't idle musings fun. ;) Andy |
|
From: Andy K. <and...@gm...> - 2010-09-14 05:55:38
|
On 12 September 2010 21:51, Peter wrote: > Hi, > > I just downloaded the latest msys package. > > If I have a directory name or file name in non-English character, > ls.exe cannot display it correctly. all of characters displayed as ?????. As long as those characters are part of the system default codepage (probably CP1252), ls --show-control-chars will show them. The reason is that MSYS is limited to the "C" locale, where only the ASCII characters from 0x20 to 0x7E are considered printable characters, and by default, ls replaces non-printable characters with question marks. To enable entering non-ASCII characters on the bash command line, open ~/.inputrc and change the relevant settings to this: set input-meta on set output-meta on set convert-meta off Delete the meta-flag setting, which is just a synonym for 'input-meta' anyway. Again though, only characters in the default codepage will work. > if I have a file 01.txt contains non-English characters, > cat.exe works fine and can display correctly. However, less.exe doesn't work and will prompt: > "01.txt" may be a binary file. See it anyway? > > it doens't display correctly after I typed "yes". > > if cat.exe can work correctly, not sure how hard to get ls.exe and less.exe to work right? No problem with 'less' here. Andy |
|
From: Peter <one...@ya...> - 2010-09-14 06:39:52
|
--- On Mon, 9/13/10, Andy Koppe <and...@gm...> wrote:
> As long as those characters are part of the system default
> codepage
> (probably CP1252), ls --show-control-chars will show them.
Hi Andy,
excellent. it works fine now. thanks for your detailed explanation about it. can we just make "-show-control-chars" enabled for ls by default
and eliminate such a problem for all?
> > "01.txt" may be a binary file. See it anyway?
> >
> > it doens't display correctly after I typed "yes".
> >
> > if cat.exe can work correctly, not sure how hard
> to get ls.exe and less.exe to work right?
>
> No problem with 'less' here.
I tried a different machine, same problem exists for less.
it will prompt:
"01.txt" may be a binary file. See it anyway?
then, display messed up text.
however, cat.exe works fine without such a problem.
We are close to resolve this problem without installing gnuwin32 or fork.
Thanks.
Peter
|
