Re: batch script execution failing with 255 exit code in cygwin 1.7.28
Greetings, Prakash Babu! > thanks Christopher. > I found the following archive which introduced this fix > (http://cygwin.com/ml/cygwin-patches/2014-q1/msg00017.html) > I feel this causes an inconsistent behavior when batch scripts are > executed using command interpreter(cmd.exe) and cygwin. > There are some generic batch script we might give to users where some > might execute using cmd.exe and some using cygwin(especially remotely > using ssh) and I would be expecting the same behavior in both places. > Also my existing batch script handles argument a=b in a way where I > obtain 'a' using %1 and 'b' using %2 and this behavior is broken now. I would suggest using bash instead of cmd. Since you are running SSH anyway, you are likely to have bash, too. As powerful CMD is, it's cumbersome to use, and nowhere near as powerful, as POSIX shell, not to mention full power of BASH. -- WBR, Andrey Repin (anrdae...@yandex.ru) 17.02.2014, <09:44> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: batch script execution failing with 255 exit code in cygwin 1.7.28
thanks Christopher. I found the following archive which introduced this fix (http://cygwin.com/ml/cygwin-patches/2014-q1/msg00017.html) I feel this causes an inconsistent behavior when batch scripts are executed using command interpreter(cmd.exe) and cygwin. There are some generic batch script we might give to users where some might execute using cmd.exe and some using cygwin(especially remotely using ssh) and I would be expecting the same behavior in both places. Also my existing batch script handles argument a=b in a way where I obtain 'a' using %1 and 'b' using %2 and this behavior is broken now. thanks, Prakash -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Little cygpath improvement request
On Sun, Feb 16, 2014 at 7:07 PM, Andy Hall wrote > Goodness. If code cleanliness is the issue, Why not simply hide this construct > in a function? Really this whole thread is a joke. He needs to just cygpath -ml "$2" &>/dev/null as others have said and be done with it. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: batch script execution failing with 255 exit code in cygwin 1.7.28
On Sun, Feb 16, 2014 at 10:35:32PM -0500, Christopher Faylor wrote: >On Mon, Feb 17, 2014 at 08:05:45AM +0530, Prakash Babu wrote: >>Was there any reason why just =(equalto) was removed as a command line >>separator for cygwin 1.7.28 , while the other delimiters like comma >>are still supported ? This is causing existing batch files that use >>equalto(=) as a command line delimiter to fail with cygwin 1.7.28 > >Search the archives. Specifically, the cygwin-patches archives. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: batch script execution failing with 255 exit code in cygwin 1.7.28
On Mon, Feb 17, 2014 at 08:05:45AM +0530, Prakash Babu wrote: >Was there any reason why just =(equalto) was removed as a command line >separator for cygwin 1.7.28 , while the other delimiters like comma >are still supported ? This is causing existing batch files that use >equalto(=) as a command line delimiter to fail with cygwin 1.7.28 Search the archives. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: batch script execution failing with 255 exit code in cygwin 1.7.28
thanks Christopher for your response.
This is the observation I made wrt to the command line delimiters for
batch files.
cmd.exe delimiters
==
space,
equalto(=)
semicolon (;)
comma(,)
cygwin 1.7.27 delimiters
==
space
quotes("")
equalto(=)
comma(,)
cygwin 1.7.28 delimiters
===
space
quotes("")
comma(,)
equalto(=) not supported
Was there any reason why just =(equalto) was removed as a command line
separator for cygwin 1.7.28 , while the other delimiters like comma
are still supported ? This is causing existing batch files that use
equalto(=) as a command line delimiter to fail with cygwin 1.7.28
thanks,
Prakash
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Little cygpath improvement request
>
> On Sun, Feb 16, 2014 at 12:30 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote
> > if [ ! -z "$2" ] ; then NATIVE="$(cygpath -ml "$2")" ; fi
>
> That might better be written as this
>
> [ "$2" ] && NATIVE=$(cygpath -ml "$2")
>
> You do not need the extra quotes when setting a variable in this way.
>
Goodness. If code cleanliness is the issue, Why not simply hide this construct
in a function?
function dospath() {
[ "$1" ] && cygpath -ml "$1"
}
Then
NATIVE=$(dospath $1)
Which is about as simple and clear as it gets.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Little cygpath improvement request
On Sun, Feb 16, 2014 at 12:30 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote > if [ ! -z "$2" ] ; then NATIVE="$(cygpath -ml "$2")" ; fi That might better be written as this [ "$2" ] && NATIVE=$(cygpath -ml "$2") You do not need the extra quotes when setting a variable in this way. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Clearing the buffer after quitting LESS, MAN, VIM etc.
Greetings, Christopher Faylor! >>> There is still one more difference between Cygwin and, e.g., xterm >>> though. The scroll buffer is still there when you enter a full screen >>> session like vim or less. So you can scroll up to it and really cause >>> confusion. It's possible to fix that behavior but it would be really >>> tricky. I'm not sure I want to complicate the console handling code >>> for this one corner case. >> >>I don't have any expertise in trickyness of this task, but I know application, >>that does exactly this. >>Far manager shrink console output buffer to console window size by default, >>when starting up. >>The file you're looking for is >>http://farmanager.googlecode.com/svn/trunk/unicode_far/console.cpp > I wasn't implying that I don't know how to do it. It is tricky to get > right for Cygwin. Ahha, makes sense. Thought that since you are recording console buffer already, this should be kind of trivial to flip console buffer size back and forth without loosing content, but I can imagine, what a mess it could become when additional restrictions apply, been working with NT console myself in the past. -- WBR, Andrey Repin (anrdae...@yandex.ru) 17.02.2014, <04:23> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Clearing the buffer after quitting LESS, MAN, VIM etc.
On Mon, Feb 17, 2014 at 12:46:37AM +0400, Andrey Repin wrote: >Greetings, Christopher Faylor! >> There is still one more difference between Cygwin and, e.g., xterm >> though. The scroll buffer is still there when you enter a full screen >> session like vim or less. So you can scroll up to it and really cause >> confusion. It's possible to fix that behavior but it would be really >> tricky. I'm not sure I want to complicate the console handling code >> for this one corner case. > >I don't have any expertise in trickyness of this task, but I know application, >that does exactly this. >Far manager shrink console output buffer to console window size by default, >when starting up. >The file you're looking for is >http://farmanager.googlecode.com/svn/trunk/unicode_far/console.cpp I wasn't implying that I don't know how to do it. It is tricky to get right for Cygwin. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Clearing the buffer after quitting LESS, MAN, VIM etc.
Greetings, Christopher Faylor! > There is still one more difference between Cygwin and, e.g., xterm > though. The scroll buffer is still there when you enter a full screen > session like vim or less. So you can scroll up to it and really cause > confusion. It's possible to fix that behavior but it would be really > tricky. I'm not sure I want to complicate the console handling code > for this one corner case. I don't have any expertise in trickyness of this task, but I know application, that does exactly this. Far manager shrink console output buffer to console window size by default, when starting up. The file you're looking for is http://farmanager.googlecode.com/svn/trunk/unicode_far/console.cpp -- WBR, Andrey Repin (anrdae...@yandex.ru) 16.02.2014, <23:50> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Little cygpath improvement request
Greetings, Corinna Vinschen! >> > I'm getting a bit puzzled. If it's only the message you don't want, >> > then why not just send this message to /dev/null??? >> >> Because the message serves no purpose in every use case I could think about. >> That, aside the fact it needs to create a redirection. >> >> > NATIVE=$(cygpath -ml "$2" 2>/dev/null) > And what's the problem with redirections? > I fail to see the big difference between adding a redirection > compared to adding an option character. I think we're nearing the border of the forest here. (The one that you can't see behind trees.) I understand that you see no problem in doing additional work at creating a redirection, because computers are so powerful nowadays, resources are so plentiful, nobody care... but I, myself, prefer the "it's just works" approach when it comes to program development. Or in other words, "sensible defaults are better, than a lot of options." In this case, I'm in for removing the message AND option as both are redundant. P.S. And it's not the first time I'm fighting the case of expected usage pattern against real-life applications. The message is "generally useful", but such case is from artificial breed of generic cases, that does not survive in the wild. -- WBR, Andrey Repin (anrdae...@yandex.ru) 16.02.2014, <22:25> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Little cygpath improvement request
Corinna Vinschen sent the following at Sunday, February 16, 2014 10:11 AM >> > NATIVE=$(cygpath -ml "$2" 2>/dev/null) > >And what's the problem with redirections? > >I fail to see the big difference between adding a redirection compared >to adding an option character. Some of us avoid redirections because we do it so rarely that getting it correct becomes a long experimental process. But as an alternative to redirection, one can test for an empty path. if [ ! -z "$2" ] ; then NATIVE="$(cygpath -ml "$2")" ; fi - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 16 12:09, Christopher Faylor wrote: > On Sun, Feb 16, 2014 at 03:48:35PM +0100, Corinna Vinschen wrote: > >On Feb 16 12:56, Corinna Vinschen wrote: > >>On Feb 16 03:30, Warren Young wrote: > >>>On Feb 15, 2014, at 5:50 AM, Corinna Vinschen wrote: > No, that's not right. We have two mechanisms implemented you can > choose three out of four possible combinations: > > files only db only files, then db > >>> > >>>Yes, I realize that. > >>> > >>>While composing the previous email, I considered a 2-Boolean design: > >>> > >>>ignore_db=false ignore_files=false > >>> > >>>I rejected that design when I realized that ignore_files is redundant > >>>with respect to /etc/foo file existence. If the files are present, use > >>>them. If not, you have a DB-only configuration. > >> > >>What if an admin wants to avoid that files are read at all, even if a > >>user manages to generate them? > > > >Anyway, I'm willing to switch from /etc/nsswitch.conf to something > >else. > > Can you summarize why this is necessary? I haven't really followed how > we got to the point where documented nscd.conf/nsswitch.conf > functionality wouldn't be sufficient. Documented for Linux or documented for Cygwin? Most of the settings now done in nsswitch.conf have nothing to do with what is done in nsswitch.conf on other OSes. These settings have no equivalent to the settings done in nscd.conf either. Except for the passwd: and group: settings, they are plain Cygwin only. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpduzoPvwUzn.pgp Description: PGP signature
Re: Installer cannot write to Cygwin's /usr/local/etc
On 02/16/2014 12:38 PM, Gerry Reno wrote: > > I ran the acl checks and can find no difference between them which leads to > this being yet another WiX/MSI installer > issue which doesn't surprise me. > > Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local > $ getfacl bin > # file: bin > # owner: Administrator > # group: Domain Users > user::rwx > group::r-x > mask:rwx > other:r-x > default:user::rwx > default:group::r-x > default:other:r-x > > > Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local > $ getfacl etc > # file: etc > # owner: Administrator > # group: Domain Users > user::rwx > group::r-x > mask:rwx > other:r-x > default:user::rwx > default:group::r-x > default:other:r-x > > > Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local > $ cacls bin > C:\cygwin\usr\local\bin SECRET\Administrator:F > SECRET\Domain Users:R > Everyone:R > CREATOR OWNER:(OI)(CI)(IO)F > CREATOR GROUP:(OI)(CI)(IO)R > Everyone:(OI)(CI)(IO)R > > > Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local > $ cacls etc > C:\cygwin\usr\local\etc SECRET\Administrator:F > SECRET\Domain Users:R > Everyone:R > CREATOR OWNER:(OI)(CI)(IO)F > CREATOR GROUP:(OI)(CI)(IO)R > Everyone:(OI)(CI)(IO)R > > > Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local > $ Icacls bin > bin SECRET\Administrator:(F) > SECRET\Domain Users:(RX) > Everyone:(RX) > CREATOR OWNER:(OI)(CI)(IO)(F) > CREATOR GROUP:(OI)(CI)(IO)(RX) > Everyone:(OI)(CI)(IO)(RX) > > Successfully processed 1 files; Failed processing 0 files > > Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local > $ Icacls etc > etc SECRET\Administrator:(F) > SECRET\Domain Users:(RX) > Everyone:(RX) > CREATOR OWNER:(OI)(CI)(IO)(F) > CREATOR GROUP:(OI)(CI)(IO)(RX) > Everyone:(OI)(CI)(IO)(RX) > > Successfully processed 1 files; Failed processing 0 files > > > Thanks for your help. > In case anyone else runs into this I found the problem, which was that on both these machines there was an already existing install of Cygwin. I removed these existing installations and then reran the installer which called out and ran Cygwin setup which created a whole new Cygwin installation. This time the installer had no problem copying files into the Cygwin installation. For completeness here are the acls from the new Cygwin installations. As you can see the installer uses SYSTEM as the user account due to perMachine scope and elevated privileges required by UAC. Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ getfacl bin # file: bin # owner: SYSTEM # group: SYSTEM user::rwx group::rwx mask:rwx other:r-x default:user::rwx default:group::r-x default:other:r-x Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ getfacl etc # file: etc # owner: SYSTEM # group: SYSTEM user::rwx group::rwx mask:rwx other:r-x default:user::rwx default:group::r-x default:other:r-x Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ cacls bin C:\cygwin\usr\local\bin NT AUTHORITY\SYSTEM:F NT AUTHORITY\SYSTEM:R Everyone:R CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)(IO)R Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ cacls etc C:\cygwin\usr\local\etc NT AUTHORITY\SYSTEM:F NT AUTHORITY\SYSTEM:R Everyone:R CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)(IO)R Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ Icacls bin bin NT AUTHORITY\SYSTEM:(F) NT AUTHORITY\SYSTEM:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ Icacls etc etc NT AUTHORITY\SYSTEM:(F) NT AUTHORITY\SYSTEM:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files I don't know if there are any other ramifications of Cygwin being installed under SYSTEM account but so far everything seems to work. Again, thanks for the help tracking this down. Gerry -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:
Re: directory y: exe runs properly, directory x: exe quits straightaway
please reply to the list On 16/02/2014 18:24, lothar atheling wrote: On Fri, Feb 14, 2014, at 11:31 AM, Marco Atzeri wrote: On 14/02/2014 18:44, lothar atheling wrote: i am porting an application built with Visual C++ to build under Mingw gcc (CXX=/usr/bin/i686-w64-mingw32-g++) this is not the mingw list... this is a cygwin problem being reported to the cygwin list it is almost certainly not a compiler / toolchain issue. for me it is a mingw program issue. Just personal opinion. this behaviour has some reproducibility: if i copy the development directory with tar and rebuild, the behaviour represents, whereas if i make a new build directory, copy the sources and the makefile and rebuild, the behaviour vanishes. ldd is not the right tool for this search. It does not show the DLLs not available on path try: objdump -x mung |grep "DLL Name" i had tried objdump -x mung.exe for these exes - they were identical in all directories. That is expected. "objdump -x" provides all the info, while "ldd" only the list of dlls available on the PATH i mentioned that the bash environment and the cygwin environments were also the same in all cases. to me it seems than in one case >>> $ ldd mung.exe >>> ntdll.dll => /xp0/WINDOWS/system32/ntdll.dll (0x7c90) >>> kernel32.dll => /xp0/WINDOWS/system32/kernel32.dll (0x7c80) ldd find only these dll's in the PATH While in the second case >>> while in the copy directory, ldd shows: >>> $ ldd mung.exe >>> ntdll.dll => /xp0/WINDOWS/system32/ntdll.dll (0x7c90) >> [cut] >>> glut32.dll => /usr/bin/glut32.dll (0x1000) >>> WINMM.dll => /xp0/WINDOWS/system32/WINMM.dll (0x76b4) >>> libgcc_s_sjlj-1.dll => >>> /usr/i686-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll >>> (0x6cec) >>> libstdc++-6.dll => >>> /usr/i686-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll >>> (0x6fc4) >>> ldd find all dll's on the PATH Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Installer cannot write to Cygwin's /usr/local/etc
On 02/16/2014 02:14 AM, Marco Atzeri wrote: > On 16/02/2014 03:12, Gerry Reno wrote: >> I have a Windows MSI installer that first loads Cygwin and then has a >> deferred copy of some files into /usr/local/bin >> and /usr/local/etc. >> >> The copies into /usr/local/bin succeed fine. >> >> The copies into /usr/local/etc always get Access denied. >> >> I've tried swapping them and same behavior. The files that would copy into >> /usr/local/bin now would not copy into >> /usr/local/etc. >> >> I'm seeing this behavior on Windows 7 and Windows 2008R2 w/UAC. >> >> The installer prompts the user for elevated privileges to deal with UAC. >> >> Is there some underlying difference in the way that /usr/local/bin and >> /usr/local/etc are configured in Cygwin? > > > it should be no difference. > However you can check the Windows ACL with > > $ cd /usr/local > > /usr/local > $ getfacl bin > # file: bin > # owner: marco > # group: Administrators > user::rwx > group::r-x > mask:rwx > other:r-x > default:user::rwx > default:group::r-x > default:other:r-x > > $ getfacl etc > # file: etc > # owner: marco > # group: Administrators > user::rwx > group::r-x > mask:rwx > other:r-x > default:user::rwx > default:group::r-x > default:other:r-x > > however, I will not be surprised if setup run by a MSI have additional > limitation. > > Can you install the same "package" by setup alone to compare ? > > I ran the acl checks and can find no difference between them which leads to this being yet another WiX/MSI installer issue which doesn't surprise me. Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ getfacl bin # file: bin # owner: Administrator # group: Domain Users user::rwx group::r-x mask:rwx other:r-x default:user::rwx default:group::r-x default:other:r-x Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ getfacl etc # file: etc # owner: Administrator # group: Domain Users user::rwx group::r-x mask:rwx other:r-x default:user::rwx default:group::r-x default:other:r-x Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ cacls bin C:\cygwin\usr\local\bin SECRET\Administrator:F SECRET\Domain Users:R Everyone:R CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)(IO)R Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ cacls etc C:\cygwin\usr\local\etc SECRET\Administrator:F SECRET\Domain Users:R Everyone:R CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)(IO)R Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ Icacls bin bin SECRET\Administrator:(F) SECRET\Domain Users:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files Administrator@WIN-SERVER /cygdrive/c/cygwin/usr/local $ Icacls etc etc SECRET\Administrator:(F) SECRET\Domain Users:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files Thanks for your help. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Clearing the buffer after quitting LESS, MAN, VIM etc.
On Wed, Feb 12, 2014 at 01:33:19PM +, Dawid Ferenczy wrote: >I'm working with CLI having long scrollback buffer. I need to read >something a couple of pages back, so I scroll back in the buffer. Then I >clear the screen with CTRL + L. Screen is already cleared, but only the >visible screen in the middle of scrollback buffer. When content fulfills >the whole screen and it starts to scroll, the new output is mixed with >previous buffer content. Also scrollback buffer is now messed. > >I think, that clearing of the screen with CTRL + L should work as in the >Linux terminal (e.g. Gnome Terminal). When I press CTRL + L in the middle >of scrollback buffer, it just jumps to the end of scrollback buffer. Getting that kind of functionality in the Windows console is tricky but I think it should be there in the latest snapshot. I also fixed some problems with some of the escape sequences that scroll the screen. There is still one more difference between Cygwin and, e.g., xterm though. The scroll buffer is still there when you enter a full screen session like vim or less. So you can scroll up to it and really cause confusion. It's possible to fix that behavior but it would be really tricky. I'm not sure I want to complicate the console handling code for this one corner case. The new behavior is in the latest snapshot. http://cygwin.com/snapshots/ cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ps shows same process more than once
On Sat, Feb 15, 2014 at 11:12:48AM +0800, George M. Florendo wrote: >On 12/28/13, Christopher Faylor wrote: > Oops. Sorry. Just noticed that the pids weren't "different". There > are still pathological situations where a pid can show up twice when > doing a "ps -W". I've seen the issue before but fixing it would > involve > a global process lock which would slow down Cygwin for the benefit of > a more accurate "ps -W". Oh, I'm sorry too. Didn't get to read your first sentence earlier. I'd rather have a faster cygwin more than a more accurate "ps -W". Thanks for all your help. >>> >>>Thanks for understanding. I will try to revisit this code sometime in >>>the near future to see if I can do something about this case. I had a >>>glimmer of an idea about how to fix this in the thinking room recently. >> >> This problem should be fixed in the latest snapshot. > >Thanks a lot cgf. Checked the latest snaphshot. ps -W still shows >the same process (with same PID) twice, while ps aux shows it only >once. Here, please look at process 5952: I've put up another snapshot which causes the same cygwin pid to be listed twice with two different WINPIDs which can happen when a cygwin process is started by a windows process and then execs another process. Please try it and try to let me know if it works in less than 1.5 months. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Testers needed: New passwd/group handling in Cygwin
On Sun, Feb 16, 2014 at 03:48:35PM +0100, Corinna Vinschen wrote: >On Feb 16 12:56, Corinna Vinschen wrote: >>On Feb 16 03:30, Warren Young wrote: >>>On Feb 15, 2014, at 5:50 AM, Corinna Vinschen wrote: No, that's not right. We have two mechanisms implemented you can choose three out of four possible combinations: files only db only files, then db >>> >>>Yes, I realize that. >>> >>>While composing the previous email, I considered a 2-Boolean design: >>> >>>ignore_db=false ignore_files=false >>> >>>I rejected that design when I realized that ignore_files is redundant >>>with respect to /etc/foo file existence. If the files are present, use >>>them. If not, you have a DB-only configuration. >> >>What if an admin wants to avoid that files are read at all, even if a >>user manages to generate them? > >Anyway, I'm willing to switch from /etc/nsswitch.conf to something >else. Can you summarize why this is necessary? I haven't really followed how we got to the point where documented nscd.conf/nsswitch.conf functionality wouldn't be sufficient. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Installer cannot write to Cygwin's /usr/local/etc
On Sun, Feb 16, 2014 at 09:54:21AM +0400, Andrey Repin wrote: >@CGF: Yes, I know, how it sounds. You have all rights to laugh. You also know what I can do if you continue to push this new rude personna. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Testers needed: New passwd/group handling in Cygwin
Greetings, Warren Young! >> What if an admin wants to avoid that files are read at all, even if a >> user manages to generate them? > Such an admin should adjust the permissions on /etc so normal users can’t > create files there, as on a “real” *ix. I approve of this product and/or service. -- WBR, Andrey Repin (anrdae...@yandex.ru) 16.02.2014, <20:24> Sorry for my terrible english...
Re: New passwd/group handling in Cygwin - test results and observations
Greetings, Corinna Vinschen!
>> > > > Sorry, I can't provide an easy solution, and afaik this is documented.
>> > > [...]
>> Maybe I have a simple solution. From your other mails I gather you
>> suceeded building your own Cygwin DLL.
I wasn't building cygwin1.dll specifically, but it appears it was actually
doing so as a by-product... :)
>>
>> If you apply this patch:
>>
>> Index: dcrt0.cc
>> ===
>> RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v
>> retrieving revision 1.453
>> diff -u -p -r1.453 dcrt0.cc
>> --- dcrt0.cc 10 Feb 2014 10:45:50 - 1.453
>> +++ dcrt0.cc 16 Feb 2014 15:15:44 -
>> @@ -929,14 +929,14 @@ dll_crt0_1 (void *)
>>/* Allocate cygheap->fdtab */
>>dtable_init ();
>>
>> + /* Set internal locale to the environment settings. */
>> + initial_setlocale ();
>> +
>>uinfo_init (); /* initialize user info */
>>
>>/* Connect to tty. */
>>tty::init_session ();
>>
>> - /* Set internal locale to the environment settings. */
>> - initial_setlocale ();
>> -
>>if (!__argc)
>> {
>>PWCHAR wline = GetCommandLineW ();
>>
>> and rebuild your Cygwin DLL, does it make a difference? In theory
>> it should work as expected now even with ru_RU.CP866.
> It works for me when using german umlauts with LANG=de_DE.cp1252, while
> it didn't work before, so I applied this path to CVS.
IC.
Picked the changes from CVS and rebuilding it right now.
...
Done and installed new library. All seems to be in order. Thanks for support!
And patch makes some sense to my untrained eye, too.
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 16.02.2014, <20:11>
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 16, 2014, at 4:56 AM, Corinna Vinschen wrote: > What if an admin wants to avoid that files are read at all, even if a > user manages to generate them? Such an admin should adjust the permissions on /etc so normal users can’t create files there, as on a “real” *ix. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: New passwd/group handling in Cygwin - test results and observations
On Feb 16 16:16, Corinna Vinschen wrote:
> On Feb 16 15:34, Corinna Vinschen wrote:
> > On Feb 16 17:52, Andrey Repin wrote:
> > > > Sorry, I can't provide an easy solution, and afaik this is documented.
> > > [...]
> Maybe I have a simple solution. From your other mails I gather you
> suceeded building your own Cygwin DLL.
>
> If you apply this patch:
>
> Index: dcrt0.cc
> ===
> RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v
> retrieving revision 1.453
> diff -u -p -r1.453 dcrt0.cc
> --- dcrt0.cc 10 Feb 2014 10:45:50 - 1.453
> +++ dcrt0.cc 16 Feb 2014 15:15:44 -
> @@ -929,14 +929,14 @@ dll_crt0_1 (void *)
>/* Allocate cygheap->fdtab */
>dtable_init ();
>
> + /* Set internal locale to the environment settings. */
> + initial_setlocale ();
> +
>uinfo_init (); /* initialize user info */
>
>/* Connect to tty. */
>tty::init_session ();
>
> - /* Set internal locale to the environment settings. */
> - initial_setlocale ();
> -
>if (!__argc)
> {
>PWCHAR wline = GetCommandLineW ();
>
> and rebuild your Cygwin DLL, does it make a difference? In theory
> it should work as expected now even with ru_RU.CP866.
It works for me when using german umlauts with LANG=de_DE.cp1252, while
it didn't work before, so I applied this path to CVS.
HTH,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpoYzQ9KQEOe.pgp
Description: PGP signature
Re: New passwd/group handling in Cygwin - test results and observations
On Feb 16 15:34, Corinna Vinschen wrote:
> On Feb 16 17:52, Andrey Repin wrote:
> > > Sorry, I can't provide an easy solution, and afaik this is documented.
> >
> > I don't know, how it did not hit my head earlier, but now that I think about
> > it...
> > The fact `ls' does not print correct group names, but correctly translate
> > dates... eww, wait. There's something bad happens under the hood.
> >
> > Please check this image: http://img513.imageshack.us/img513/43/jn7n.png
> > LANG is set (pre-set, before Cygwin tree start) to ru_RU.UTF-8 for mintty
> > and
> > ru_RU.CP866 for console.
> > As you can see, existing group (i.e. - "Administrators") is properly
> > translated to chosen locale, which is not the case for group "Отсутствует".
> >
> > The SID of the group "DAEMON2\Отсутствует" is
> > S-1-5-21-1801674531-1644491937-1606980848-513
> >
> > Cygwin show it as
> > -rwxr-xr-x1 197612 19712145597 мар 22 2013 xargs.exe
> >
> > which matching your description for "Accounts from the local machine's user
> > DB
> > (SAM)" (0x3+513 =197121) (and yes, the leading part of the SID is
> > matching
> > the one of the other users on this system), but the group is missing from
> > `wmic GROUP LIST' output. I presume, it was deleted at one point, or it is
> > remnants of the previous OS installation, transferred over with the disk to
> > this system. Either case explains the name of the group - "Missing" or
> > "Nonexistent". Means, it's name does not exist in current SAM database.
>
> No, it's the local group with the RID 513, which exists on *all*
> machines, but is invisible, unless you call NetUserEnum, which
> enumerates it, or you call NetUserGetInfo with the localized name.
>
> This group is called "None" in the english OS versions, "Kein" in
> the german version, "Aucun" in the french version, etc. All local
> users accounts have this group invariably set as their primary group.
>
> For some reason Microsoft decided ages ago, that this group does
> not show up in the GUI, and that it's not possible to change the primary
> group outside of domains. Why that is, I have no idea.
Maybe I have a simple solution. From your other mails I gather you
suceeded building your own Cygwin DLL.
If you apply this patch:
Index: dcrt0.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v
retrieving revision 1.453
diff -u -p -r1.453 dcrt0.cc
--- dcrt0.cc10 Feb 2014 10:45:50 - 1.453
+++ dcrt0.cc16 Feb 2014 15:15:44 -
@@ -929,14 +929,14 @@ dll_crt0_1 (void *)
/* Allocate cygheap->fdtab */
dtable_init ();
+ /* Set internal locale to the environment settings. */
+ initial_setlocale ();
+
uinfo_init (); /* initialize user info */
/* Connect to tty. */
tty::init_session ();
- /* Set internal locale to the environment settings. */
- initial_setlocale ();
-
if (!__argc)
{
PWCHAR wline = GetCommandLineW ();
and rebuild your Cygwin DLL, does it make a difference? In theory
it should work as expected now even with ru_RU.CP866.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgp2wv2P2BFrH.pgp
Description: PGP signature
Re: Little cygpath improvement request
On Feb 16 18:41, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
> >> >> >> I would like to request a small functional change for cygpath.
> >> >> >> In the event of empty given path argument (i.e. `cygpath -ml ""')
> >> >> >> silently
> >> >> >> return an empty result without error message.
> >> >> >> This would greatly simplify wrapper scripts.
> >> >>
> >> >> > Why isn't redirecting the message to /dev/null not sufficient,
> >> >> > something
> >> >> > like this (bash syntax)?
> >> >>
> >> >> Because it'll require creating a redirection? And this kind of redundant
> >> >> inserts blurring the code.
> >> >> Returning a non-zero exit code would suffice for debugging purposes.
> >> >>
> >> >> > cygpath -ml "" >/dev/null 2&>1
> >> >>
> >> >> Err, not > /dev/null !!! :D
> >>
> >> > dos_path=$( [ -n "${posix_path}" ] && cygpath -ml "${posix_path}" )
> >>
> >> > ?
> >>
> >> I appreciate the effort, bit this even MORE complicating the possible use
> >> case.
> >>
> >> Look, I'm asking for simplification without loosing functionality.
> >> If I NEED to check the path for existence, I would write something to the
> >> extent of
>
> > I'm getting a bit puzzled. If it's only the message you don't want,
> > then why not just send this message to /dev/null???
>
> Because the message serves no purpose in every use case I could think about.
> That, aside the fact it needs to create a redirection.
>
> > NATIVE=$(cygpath -ml "$2" 2>/dev/null)
And what's the problem with redirections?
I fail to see the big difference between adding a redirection
compared to adding an option character.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpl08A69EPZ2.pgp
Description: PGP signature
Re: Little cygpath improvement request
Greetings, Corinna Vinschen!
>> >> >> I would like to request a small functional change for cygpath.
>> >> >> In the event of empty given path argument (i.e. `cygpath -ml ""')
>> >> >> silently
>> >> >> return an empty result without error message.
>> >> >> This would greatly simplify wrapper scripts.
>> >>
>> >> > Why isn't redirecting the message to /dev/null not sufficient, something
>> >> > like this (bash syntax)?
>> >>
>> >> Because it'll require creating a redirection? And this kind of redundant
>> >> inserts blurring the code.
>> >> Returning a non-zero exit code would suffice for debugging purposes.
>> >>
>> >> > cygpath -ml "" >/dev/null 2&>1
>> >>
>> >> Err, not > /dev/null !!! :D
>>
>> > dos_path=$( [ -n "${posix_path}" ] && cygpath -ml "${posix_path}" )
>>
>> > ?
>>
>> I appreciate the effort, bit this even MORE complicating the possible use
>> case.
>>
>> Look, I'm asking for simplification without loosing functionality.
>> If I NEED to check the path for existence, I would write something to the
>> extent of
> I'm getting a bit puzzled. If it's only the message you don't want,
> then why not just send this message to /dev/null???
Because the message serves no purpose in every use case I could think about.
That, aside the fact it needs to create a redirection.
> NATIVE=$(cygpath -ml "$2" 2>/dev/null)
>> But if I (and the program that I would feed it to) don't care (which is often
>> the case), the message printed from cygpath doesn't add to functionality.
>>
>> P.S.
>> I've tried to rebuild it myself, but hit a roadblock.
>> While trying to rebuild only winsup/utils, this happens
> That never works. Why don't you just fetch the source archive from
> the last package and use the cygport file inside?
Because I'm building Cygwin itself the first time. When my attempt at saving
time in hope it would "just work" failed, I followed FAQ to the letter, but
got nowhere either. The list of required packages to compile it seems to be
right, though. I've eventually succeed.
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 16.02.2014, <17:33>
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 16 12:56, Corinna Vinschen wrote: > On Feb 16 03:30, Warren Young wrote: > > On Feb 15, 2014, at 5:50 AM, Corinna Vinschen wrote: > > > No, that's not right. We have two mechanisms implemented you can > > > choose three out of four possible combinations: > > > > > > files only > > > db only > > > files, then db > > > > Yes, I realize that. > > > > While composing the previous email, I considered a 2-Boolean design: > > > >ignore_db=false > >ignore_files=false > > > > I rejected that design when I realized that ignore_files is redundant with > > respect to /etc/foo file existence. If the files are present, use them. > > If not, you have a DB-only configuration. > > What if an admin wants to avoid that files are read at all, even if a > user manages to generate them? Anyway, I'm willing to switch from /etc/nsswitch.conf to something else. Let's assume we go with /etc/cygwin.conf instead. This wouldn't set a bad precedent in terms of syntax and keyword differences to configuration files existing on Linux, and it would allow to define more settings which have nothing to do with passwd/group stuff in the long run. So, how should this look like? Let's do some free floating, # /etc/cygwin.conf pwdgrp="files db" db_separator="+" db_cache="yes" db_prefix="auto" And now the new one. I have getpwent/getgrent practically ready to go. It's just missing the setting to restrict the enumeration. It occured to me that an admin or a user might want to restrict the enumeration to a specific set of domains. What about something like this? db_enum="local primary trusted_dom1 trusted_dom2" "local" and "primary" being fixed keywords for the local machine accounts and the accounts from the primary domain. Everything else is treated as a domain name of a trusted domain, and the name can be given as flat domain name as well as as dns domain name. Does that make sense? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKSaIoe19tG.pgp Description: PGP signature
Re: New passwd/group handling in Cygwin - test results and observations
On Feb 16 17:52, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> > But this is a problem not different from Linux. If you have a username > >> > with non-ASCII chars, it will use *some* encoding in the passwd DB, > >> > usually UTF-8 these days. If you then change the codeset in your > >> > application, you will still get your username in UTF-8. It won't be > >> > changed on the fly, just because your application calls setlocale. > >> > >> I understand it (mostly), but there's actually two issues, not one. > >> One issue is the display part, where names are output for user consumption. > >> Another can be observed in, i.e., rsync, and file access in general > >> (remember > >> the discussion about accessing long directory names in unicode). > >> Changing LANG variable DO matter for the latter, and you may only hope that > >> whatever is output in the former case is actually printable (thank God, > >> most > >> of the time it actually is, in case of UTF-8). > >> It is getting even more complicated, when you consider the fact, that in > >> Windows you have 2 different single-byte encodings, so-called ANSI (for GUI > >> applications) and OEM (for console). And alot of stuff making assumptions > >> without consulting with current status of things. > >> As convoluted the problem is, I think, we need some sort of solution, or at > >> the very least - documentation. > > > Sorry, I can't provide an easy solution, and afaik this is documented. > > I don't know, how it did not hit my head earlier, but now that I think about > it... > The fact `ls' does not print correct group names, but correctly translate > dates... eww, wait. There's something bad happens under the hood. > > Please check this image: http://img513.imageshack.us/img513/43/jn7n.png > LANG is set (pre-set, before Cygwin tree start) to ru_RU.UTF-8 for mintty and > ru_RU.CP866 for console. > As you can see, existing group (i.e. - "Administrators") is properly > translated to chosen locale, which is not the case for group "Отсутствует". > > The SID of the group "DAEMON2\Отсутствует" is > S-1-5-21-1801674531-1644491937-1606980848-513 > > Cygwin show it as > -rwxr-xr-x1 197612 19712145597 мар 22 2013 xargs.exe > > which matching your description for "Accounts from the local machine's user DB > (SAM)" (0x3+513 =197121) (and yes, the leading part of the SID is matching > the one of the other users on this system), but the group is missing from > `wmic GROUP LIST' output. I presume, it was deleted at one point, or it is > remnants of the previous OS installation, transferred over with the disk to > this system. Either case explains the name of the group - "Missing" or > "Nonexistent". Means, it's name does not exist in current SAM database. No, it's the local group with the RID 513, which exists on *all* machines, but is invisible, unless you call NetUserEnum, which enumerates it, or you call NetUserGetInfo with the localized name. This group is called "None" in the english OS versions, "Kein" in the german version, "Aucun" in the french version, etc. All local users accounts have this group invariably set as their primary group. For some reason Microsoft decided ages ago, that this group does not show up in the GUI, and that it's not possible to change the primary group outside of domains. Why that is, I have no idea. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYPrK2GIYfp.pgp Description: PGP signature
Re: New passwd/group handling in Cygwin - test results and observations
Greetings, Corinna Vinschen! >> > But this is a problem not different from Linux. If you have a username >> > with non-ASCII chars, it will use *some* encoding in the passwd DB, >> > usually UTF-8 these days. If you then change the codeset in your >> > application, you will still get your username in UTF-8. It won't be >> > changed on the fly, just because your application calls setlocale. >> >> I understand it (mostly), but there's actually two issues, not one. >> One issue is the display part, where names are output for user consumption. >> Another can be observed in, i.e., rsync, and file access in general (remember >> the discussion about accessing long directory names in unicode). >> Changing LANG variable DO matter for the latter, and you may only hope that >> whatever is output in the former case is actually printable (thank God, most >> of the time it actually is, in case of UTF-8). >> It is getting even more complicated, when you consider the fact, that in >> Windows you have 2 different single-byte encodings, so-called ANSI (for GUI >> applications) and OEM (for console). And alot of stuff making assumptions >> without consulting with current status of things. >> As convoluted the problem is, I think, we need some sort of solution, or at >> the very least - documentation. > Sorry, I can't provide an easy solution, and afaik this is documented. I don't know, how it did not hit my head earlier, but now that I think about it... The fact `ls' does not print correct group names, but correctly translate dates... eww, wait. There's something bad happens under the hood. Please check this image: http://img513.imageshack.us/img513/43/jn7n.png LANG is set (pre-set, before Cygwin tree start) to ru_RU.UTF-8 for mintty and ru_RU.CP866 for console. As you can see, existing group (i.e. - "Administrators") is properly translated to chosen locale, which is not the case for group "Отсутствует". The SID of the group "DAEMON2\Отсутствует" is S-1-5-21-1801674531-1644491937-1606980848-513 Cygwin show it as -rwxr-xr-x1 197612 19712145597 мар 22 2013 xargs.exe which matching your description for "Accounts from the local machine's user DB (SAM)" (0x3+513 =197121) (and yes, the leading part of the SID is matching the one of the other users on this system), but the group is missing from `wmic GROUP LIST' output. I presume, it was deleted at one point, or it is remnants of the previous OS installation, transferred over with the disk to this system. Either case explains the name of the group - "Missing" or "Nonexistent". Means, it's name does not exist in current SAM database. -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.02.2014, <21:19> Sorry for my terrible english...
Re: in6addr_any declaration
On Feb 16 00:04, Marco Atzeri wrote: > on /usr/include/cygwin/in6.h > > extern const struct in6_addr in6addr_any; > extern const struct in6_addr in6addr_loopback; > > should not a __declspec(dllimport) be added ? Why? They are not exported as dllexport either. This is not necessary since ld links in the symbols automatically, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBx9CG34E50.pgp Description: PGP signature
Re: Little cygpath improvement request
On Feb 15 22:57, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
> >> >> I would like to request a small functional change for cygpath.
> >> >> In the event of empty given path argument (i.e. `cygpath -ml ""')
> >> >> silently
> >> >> return an empty result without error message.
> >> >> This would greatly simplify wrapper scripts.
> >>
> >> > Why isn't redirecting the message to /dev/null not sufficient, something
> >> > like this (bash syntax)?
> >>
> >> Because it'll require creating a redirection? And this kind of redundant
> >> inserts blurring the code.
> >> Returning a non-zero exit code would suffice for debugging purposes.
> >>
> >> > cygpath -ml "" >/dev/null 2&>1
> >>
> >> Err, not > /dev/null !!! :D
>
> > dos_path=$( [ -n "${posix_path}" ] && cygpath -ml "${posix_path}" )
>
> > ?
>
> I appreciate the effort, bit this even MORE complicating the possible use
> case.
>
> Look, I'm asking for simplification without loosing functionality.
> If I NEED to check the path for existence, I would write something to the
> extent of
I'm getting a bit puzzled. If it's only the message you don't want,
then why not just send this message to /dev/null???
NATIVE=$(cygpath -ml "$2" 2>/dev/null)
> But if I (and the program that I would feed it to) don't care (which is often
> the case), the message printed from cygpath doesn't add to functionality.
>
> P.S.
> I've tried to rebuild it myself, but hit a roadblock.
> While trying to rebuild only winsup/utils, this happens
That never works. Why don't you just fetch the source archive from
the last package and use the cygport file inside?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpUl9DMGQX4a.pgp
Description: PGP signature
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 16 03:30, Warren Young wrote: > On Feb 15, 2014, at 5:50 AM, Corinna Vinschen wrote: > > No, that's not right. We have two mechanisms implemented you can > > choose three out of four possible combinations: > > > > files only > > db only > > files, then db > > Yes, I realize that. > > While composing the previous email, I considered a 2-Boolean design: > >ignore_db=false >ignore_files=false > > I rejected that design when I realized that ignore_files is redundant with > respect to /etc/foo file existence. If the files are present, use them. If > not, you have a DB-only configuration. What if an admin wants to avoid that files are read at all, even if a user manages to generate them? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpQv3rl9Cc6w.pgp Description: PGP signature
Re: Octave
On 14/02/2014 19:02, Marco Atzeri wrote: On 14/02/2014 18:30, Ash Hughes wrote: Thanks, what great timing :) Will there be an octave-signal package? Thanks, Ash oops octave-signal1.3.0-1 building the 64bit version, it was only on the 32bit list... Marco all uploaded Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 15, 2014, at 5:50 AM, Corinna Vinschen wrote: > I grabbed all of this including your followup > change shamelessly and added it to the text. Happy to provide it. >> It seems to me that we really only need a single Boolean setting: >> >> ignore_db=true > > No, that's not right. We have two mechanisms implemented you can > choose three out of four possible combinations: > > files only > db only > files, then db Yes, I realize that. While composing the previous email, I considered a 2-Boolean design: ignore_db=false ignore_files=false I rejected that design when I realized that ignore_files is redundant with respect to /etc/foo file existence. If the files are present, use them. If not, you have a DB-only configuration. I consider it an advantage of this design that it is not possible for the files to be present but ignored. It avoids confusion, both human and software. A person modifying /etc/passwd expects the change to take immediate effect. (Obviously SAM or AD could mask it, but…) Software that scans /etc/passwd expects that the data found within have relevance to system operation. The nonsense configuration — ignore files *and* ignore DB — is still possible to achieve with the 1-Boolean design. Set ignore_db=true and remove the /etc files. Cygwin should simply treat this as a “DB-only” configuration, since that’s the only place it *can* get answers. > It drops any check for existence, too, which > is one code point less which has to run for each getpwXXX/getgrXXX > invocation. Cygwin should check for file existence at the process tree start, where it reads /etc/nsswitch.conf. If the files are missing at that time, set the “ignore_files” flag. Cygwin should use that flag instead of explicit file existence tests for the same reason it doesn’t keep re-reading nsswitch.conf. If the files are missing at process tree start, then later created, you have to create a new process tree for the new files to be used. This is no sacrifice. If you use a 2-Boolean design, you only end up in the code fork where file checking is done if ignore_files == false. That means there is no point to checking for file existence explicitly. Just blindly try to read the files; if the file is missing, the open will fail, so your check is implicit in the attempt. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Installer cannot write to Cygwin's /usr/local/etc
On 16/02/2014 09:57, Andrey Repin wrote: Greetings, Marco Atzeri! However you can check the Windows ACL with $ cd /usr/local /usr/local $ getfacl bin I would say, if you want to see _windows_ permissions, you need to use cacls. gerfacl only show POSIX approximation of windows permissions. correct. Curious however NOTE: Cacls is now deprecated, please use Icacls. but the two provide a slight different outputs: I have no access to my Win7 box right now (I've somehow managed to lock my account while experimenting with `net user' command in the light of new Cygwin functionality, and being swamped by ongoing work load decided to postpone investigation... though it is probably worth a warning...) What icacls says about "X" meaning? (That seems to be the only difference?) http://technet.microsoft.com/en-us/library/cc753525.aspx RX (read and execute access) R (read-only access) (BTW, you can specify multiple objects for [i]cacls to inspect at once.) $ Icacls etc etc GE-MATZERI-EU\0356EU:(F) BUILTIN\Administrators:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) regards MArco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Newbie Alias and Profile questions
* Mike Rushton (Mon, 10 Feb 2014 20:15:28 -0500) > I am trying to put an alias in a .bashrc > > alias clear='printf "\033c"' clear is part of the ncurses package, so I would simply install this. > But what .bashrc do I put this in ? in /ect/skel or the one my user > directory. I put this code in and it seems to get overwritten. > I don't understand what I am doing wrong. /etc/skel is a template directory for new users. > It is a minor thing that i can't clear the screen, but i want to work at > this and try to fix this. > > Then I want to add a script to my profile. but what one the > .profile or .bash_profile ? The two bash specific files you need to know are .bash_profile and .bashrc. Bash is different to other shells in that it will only read one of those two depending on whether bash is run as a login shell or not. The recommended way is to source .bashrc from .bash_profile (this is already the Cygwin default) and to leave .bash_profile empty. Put everything you need into .bashrc. Forget about .profile. It's only needed for backward compatibility and not an official bash file. Thorsten -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Installer cannot write to Cygwin's /usr/local/etc
Greetings, Marco Atzeri! >>> However you can check the Windows ACL with >> >>> $ cd /usr/local >> >>> /usr/local >>> $ getfacl bin >> >> I would say, if you want to see _windows_ permissions, you need to use cacls. >> gerfacl only show POSIX approximation of windows permissions. >> >> > correct. > Curious however > NOTE: Cacls is now deprecated, please use Icacls. > but the two provide a slight different outputs: I have no access to my Win7 box right now (I've somehow managed to lock my account while experimenting with `net user' command in the light of new Cygwin functionality, and being swamped by ongoing work load decided to postpone investigation... though it is probably worth a warning...) What icacls says about "X" meaning? (That seems to be the only difference?) (BTW, you can specify multiple objects for [i]cacls to inspect at once.) >$ Icacls etc > etc GE-MATZERI-EU\0356EU:(F) > BUILTIN\Administrators:(RX) > Everyone:(RX) > CREATOR OWNER:(OI)(CI)(IO)(F) > CREATOR GROUP:(OI)(CI)(IO)(RX) > Everyone:(OI)(CI)(IO)(RX) > $ Icacls bin > bin GE-MATZERI-EU\0356EU:(F) > BUILTIN\Administrators:(RX) > Everyone:(RX) > CREATOR OWNER:(OI)(CI)(IO)(F) > CREATOR GROUP:(OI)(CI)(IO)(RX) > Everyone:(OI)(CI)(IO)(RX) > $ cacls etc > E:\cygwin\usr\local\etc GE-MATZERI-EU\0356EU:F > BUILTIN\Administrators:R > Everyone:R > CREATOR OWNER:(OI)(CI)(IO)F > CREATOR GROUP:(OI)(CI)(IO)R > Everyone:(OI)(CI)(IO)R > $ cacls bin > E:\cygwin\usr\local\bin GE-MATZERI-EU\0356EU:F > BUILTIN\Administrators:R > Everyone:R > CREATOR OWNER:(OI)(CI)(IO)F > CREATOR GROUP:(OI)(CI)(IO)R > Everyone:(OI)(CI)(IO)R -- WBR, Andrey Repin (anrdae...@yandex.ru) 16.02.2014, <12:50> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Installer cannot write to Cygwin's /usr/local/etc
On 16/02/2014 08:27, Andrey Repin wrote: Greetings, Marco Atzeri! However you can check the Windows ACL with $ cd /usr/local /usr/local $ getfacl bin I would say, if you want to see _windows_ permissions, you need to use cacls. gerfacl only show POSIX approximation of windows permissions. correct. Curious however NOTE: Cacls is now deprecated, please use Icacls. but the two provide a slight different outputs: $ Icacls etc etc GE-MATZERI-EU\0356EU:(F) BUILTIN\Administrators:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) $ Icacls bin bin GE-MATZERI-EU\0356EU:(F) BUILTIN\Administrators:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) $ cacls etc E:\cygwin\usr\local\etc GE-MATZERI-EU\0356EU:F BUILTIN\Administrators:R Everyone:R CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)(IO)R $ cacls bin E:\cygwin\usr\local\bin GE-MATZERI-EU\0356EU:F BUILTIN\Administrators:R Everyone:R CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)(IO)R cheers Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
