problem with make 4.4.1-2 or gcc-fortran 11.4.0-1
Hello, I am trying to install a software which requires the libraries gcc-fortran, make, libarpack-devel, liblapack-devel, libnetcdf-fortran-devel, git. As I did and ran the commands given below, git clone https://github.com/Aida-Alvera/DINEOF cd DINEOF/ cp config.mk.template config.mk make The make command is showing the problem as Makefile:30: Compilers/Windows_NT-gfortran.mk: No such file or directory make: *** No rule to make target 'Compilers/Windows_NT-gfortran.mk'. Stop. I am keeping Linux as my default OS but it is asking for the Windows_NT-gfortran.mk any clue or help will be appreciated Thank you *Arnab Paul,* *PhD Graduate Student,* *Louisiana State University,* *United States of America* -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Set a different C compiler
Hi there, I tried to build a HelloWorld project using the " cmake CMakeList.txt " way. In the CMakeList.txt file, I want to use the specific c and cxx compilers set(CMAKE_LEGACY_CYGWIN_WIN32 0) #cmake_minimum_required(VERSION 2.6) project(HelloWorld) set (CMAKE_C_COMPILER icl) set (CMAKE_CXX_COMPILER /cygdrive/c/PROGRA~2/Intel/MPI/501~1.037/intel64/bin/mpicc) set (CMAKE_CXX_FLAGS "-O3") But the default c compiler is called instead, see below: $ cmake CMakeLists.txt -- The C compiler identification is MSVC 18.0.21005.1 -- The CXX compiler identification is MSVC 18.0.21005.1 -- Check for working C compiler: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/BIN/amd64/cl.exe -- Check for working C compiler: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/BIN/amd64/cl.exe -- broken CMake Error at /usr/share/cmake-3.14.5/Modules/CMakeTestCCompiler.cmake:60 (message): The C compiler How to deal with this issue? Thanks, Paul -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
mintty emacs-nox pseudorandom color dimming
Dear Sirs: After recently updating my cygwin installation, emacs-nox now pseudorandomly dims some characters after the cursor passes through a character's position. I don't think the problem lies with emacs-nox, but rather with mintty. I say this as the color dimming happens when one is using local emacs-nox within a mintty or using remote emacs-nox after sshing within a mintty. After I first discovered the dimming problem I noticed a separate problem with the backspace key in ssh sessions. I then noticed that there was yet another more recent mintty update, so I thought that I'd try that. After applying that update, the backspace problem resolved itself. However, the character dimming problem remains. Regards, Paul Ausbeck -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Unable to test the Cisco ISO Image in GNS3
1 [main] dynamips 12636 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem tothe public mailing list cygwin@cygwin.comCisco Router Simulation Platform (version 0.2.12-x86/Windows stable)Copyright (c) 2005-2011 Christophe Fillot.Build date: Mar 28 2014 12:41:27 Local UUID: 4b205266-5788-41cb-a243-3e08905da74c Unable to create lock file "c3600_i0_lock".VM default: unable to create instance!c3600: unable to create instance default! C:\Program Files\GNS3> Serge A PaulNetwork AdministratorCompTIA Network +, Cisco CCNA Certified786-704-6636 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Can I find where cygwin is installed (for automation purposes)
On Wed, 15 Apr 2020 at 19:31, René Berber via Cygwin wrote: > > On 4/15/2020 1:10 PM, Paul Moore via Cygwin wrote: > > [snip] > > Thanks. Can you explain what the \?? prefix on the Installations > > values is about? I'm nervous that there's something going on there > > that means that just ignoring the first 3 characters isn't > > sufficient... ;-) > > https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats > > Look for "DOS device paths" Thanks. That's \\?\C:\... and what I'm seeing is \??\C:\... Is that just a typo/bug? That's the discrepancy that was confusing me :-( Paul -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Can I find where cygwin is installed (for automation purposes)
On Wed, 15 Apr 2020 at 16:54, Marco Atzeri via Cygwin wrote: > > Am 15.04.2020 um 15:29 schrieb Paul Moore via Cygwin: > > On Wed, 15 Apr 2020 at 11:54, Csaba Ráduly via Cygwin > > wrote: > > > >> On my machine, I have a > >> > >> HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup > >> > >> key, which contains a string value named "rootdir" with the date > >> "C:\cygwin64". > > > > Thanks, that looks more useful. I didn't think to check there as I > > didn't recall having run the setup as "All users" so I assumed > > everything would be in HKCU. I should have checked! > > Paul > > -- > > > Pay attention that Setup links to the last updated one 64 or 32bit > > Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Setup > Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cygwin\Setup > > Installations report all if more are installed (borderline case, maybe) > > Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations > Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cygwin\Installations > > both version 32 and 64 bit are reported on > > Computer\HKEY_CURRENT_USER\Software\Cygwin\Installations Thanks. Can you explain what the \?? prefix on the Installations values is about? I'm nervous that there's something going on there that means that just ignoring the first 3 characters isn't sufficient... ;-) Paul -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
setup-x86_64.exe --quiet-mode issues using Management Tools
Hello Cygwin Support, I am trying to install Cygwin silently through a management tool like SCCM (called Bigfix). I went through the FAQ on your website to see what commands/switches existed. I would like to install silently without any user interaction and so I attempted to use setup-x86_64.exe --quiet-mode and I get into an infinite loop for the installation. Bigfix tells me that the installation is waiting for user response and will not continue. It gets stuck and can't start/finish the installation. Is there any suggestions on what I can try? I also want to install a bunch of packages during the installation but thought I would try to start at a completely silent installation firsts. I have also checked forums as well online to see if anyone else had issues. I found a one forum where someone is having the same issue with no resolution found here: https://www.itninja.com/question/cygwin-realy-silent-installation-no-progress-window-with-option-to-counsel Thanks, Paul ___ For IT support, please E-mail: fsmh...@northwestern.edu | Phone: 847-491-HELP Paul Isaacson Senior Technical Support Specialist, Client Management Northwestern University Feinberg School of Medicine Information Technology 710 N. Lake Shore Drive, 7th Floor Chicago, Illinois 60611 312.503.6159 office paul_isaac...@northwestern.edu feinberg.northwestern.edu/it -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Can I find where cygwin is installed (for automation purposes)
On Wed, 15 Apr 2020 at 13:43, Thomas Wolff wrote: > >> There's HKCU\Software\Cygwin\Installations, but that seems to use \?? > >> prefixes on the PATH, which I'm not sure how to interpret > Running that script within cygwin? `mount | grep " / "` As I said, I'm trying to find cygwin, so I can't run anything from within cygwin at this point :-( Paul -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Can I find where cygwin is installed (for automation purposes)
On Wed, 15 Apr 2020 at 11:54, Csaba Ráduly via Cygwin wrote: > On my machine, I have a > > HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup > > key, which contains a string value named "rootdir" with the date > "C:\cygwin64". Thanks, that looks more useful. I didn't think to check there as I didn't recall having run the setup as "All users" so I assumed everything would be in HKCU. I should have checked! Paul -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Can I find where cygwin is installed (for automation purposes)
I'm trying to write an automation script that works on a number of machines. I know that on all machines Cygwin will be installed, but I cannot guarantee that (1) it will be in the same location on each PC, or (2) that it will be in PATH. There's HKCU\Software\Cygwin\Installations, but that seems to use \?? prefixes on the PATH, which I'm not sure how to interpret (I know about \\?\ prefixes, but this is different, I assume?), and it also includes some non-Cygwin things (one machine I have, has \??\C:\PROGRA~1\ConEmu\ConEmu So far, the best I can see is to try every entry in there, strip \??, and look for a cygwin1.dll, and use the first entry I find that works. But that seems a bit arbitrary. Is there a better way? Thanks, Paul -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash
Interesting. Maybe codepage-related issues, then. Sorry, I'm out of my
depth now, I'll leave it to someone else to diagnose further.
On Sun, 22 Mar 2020 at 19:54, Jay Libove wrote:
>
> Good suggestion, deleting files one by one. It's not just one file, but it
> does seem to have something to do with some file name patterns.
> I think I've got it. It's accented characters.
> I live in Spain. Spanish has accented characters such as "Asociación".
> When I remove all files containing any accented character in their name, the
> problem goes away.
> So the theory now is that the Cygwin argv-processing code has a problem with
> áccented charàcters ...
> -Jay
>
> -Original Message-
> From: Paul Moore
> Sent: Sunday, 22 March 2020 20:42
> To: Jay Libove
> Cc: cygwin@cygwin.com
> Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No
> such file or directory" in Windows CMD shell, but works okay in bash
>
> Have you tried deleting files one by one, to see if the issue is related to a
> single file (sorry if this is an obvious suggestion that you've already
> tried).
>
> In Cygwin bash, it's the shell that glob-expands wildcards before calling
> your program (e.g. ls), and in find, it's the find code that does the glob
> matching. But when running Cygwin utilities from a Windows shell, it's the
> Cygwin argv-processing code linked into the executable that does the
> glob-expansion. So it's reasonable to me that you should see the issue only
> with CMD, and not with bash or find. But that only confirms what bit of code
> is involved - not what the actual problem is :-(
>
> I don't actually know much about how the cygwin glob code actually works (my
> main involvement with it has been to confirm that it doesn't suit my specific
> needs, and to work out a way to bypass it...) so I can only offer fairly
> basic suggestions, I'm afraid...
>
> Paul
>
> On Sun, 22 Mar 2020 at 19:27, Jay Libove wrote:
> >
> > Thanks Paul, both for your initial reply, and your follow-up.
> >
> > In this case it's not a matter case sensitivity.
> > I've verified that, in one of the example cases, there are both *.pdf and
> > *.PDF files in the subject directory.
> > Both 'ls *.pdf' and 'ls *.PDF' produce the "ls: cannot access '*.whatever':
> > No such file or directory" error.
> >
> > (Nor, to the other respondent's question, as I pointed out in my original
> > post, is it ACLs, as I did check CACLS before posting).
> >
> > I also tried copying (using Windows CMD "COPY") *.pdf (so being under
> > Windows, not Cygwin, it matches all cases) from a subject directory to a
> > new test directory.
> > In the resulting copy in the new test directory, the Cygwin shell expansion
> > problem persists.
> >
> > Here's an interesting twist:
> > C:> cd c:\bin\cygwin64\bin
> > C:> ln gnufind.exe find.exe # I do this to allow me to differentiate
> > between Windows' built-in very limited FIND command, and GNU/Cygwin's far
> > superior find command.
> > C:> cd \my\test\directory
> > C:> gnufind . -name *.pdf -print
> > [ successfully returns all *.pdf {lower case only} files in the
> > subject directory ] C:> gnufind . -name *.PDF -print [ successfully
> > returns all *.pdf {upper case only} files in the subject directory ]
> >
> > I'm pretty sure that Cygwin 'find' does NOT try to emulate shell globbing
> > the way 'ls' does, so it makes sense that this works, and it supports the
> > theory that something weird is going on between how Cygwin does shell
> > expansion when under Windows CMD vs. when fully within the Cygwin
> > environment (under bash where of course bash is doing the shell expansion,
> > and ls or other Cygwin commands don't have to).
> >
> > Does any of this help pinpoint the problem further?
> >
> > thanks again,
> > -Jay
> >
> > -Original Message-
> > From: Paul Moore
> > Sent: Sunday, 22 March 2020 20:09
> > To: Jay Libove
> > Cc: cygwin@cygwin.com
> > Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf':
> > No such file or directory" in Windows CMD shell, but works okay in
> > bash
> >
> > Is this because cygwin globbing is (by default) case sensitive? You could
> > set the CYGWIN environment variable to "glob:ignorecase" to get
> > case-insensitive behaviour.
> >
>
Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash
Have you tried deleting files one by one, to see if the issue is
related to a single file (sorry if this is an obvious suggestion that
you've already tried).
In Cygwin bash, it's the shell that glob-expands wildcards before
calling your program (e.g. ls), and in find, it's the find code that
does the glob matching. But when running Cygwin utilities from a
Windows shell, it's the Cygwin argv-processing code linked into the
executable that does the glob-expansion. So it's reasonable to me that
you should see the issue only with CMD, and not with bash or find. But
that only confirms what bit of code is involved - not what the actual
problem is :-(
I don't actually know much about how the cygwin glob code actually
works (my main involvement with it has been to confirm that it doesn't
suit my specific needs, and to work out a way to bypass it...) so I
can only offer fairly basic suggestions, I'm afraid...
Paul
On Sun, 22 Mar 2020 at 19:27, Jay Libove wrote:
>
> Thanks Paul, both for your initial reply, and your follow-up.
>
> In this case it's not a matter case sensitivity.
> I've verified that, in one of the example cases, there are both *.pdf and
> *.PDF files in the subject directory.
> Both 'ls *.pdf' and 'ls *.PDF' produce the "ls: cannot access '*.whatever':
> No such file or directory" error.
>
> (Nor, to the other respondent's question, as I pointed out in my original
> post, is it ACLs, as I did check CACLS before posting).
>
> I also tried copying (using Windows CMD "COPY") *.pdf (so being under
> Windows, not Cygwin, it matches all cases) from a subject directory to a new
> test directory.
> In the resulting copy in the new test directory, the Cygwin shell expansion
> problem persists.
>
> Here's an interesting twist:
> C:> cd c:\bin\cygwin64\bin
> C:> ln gnufind.exe find.exe # I do this to allow me to differentiate between
> Windows' built-in very limited FIND command, and GNU/Cygwin's far superior
> find command.
> C:> cd \my\test\directory
> C:> gnufind . -name *.pdf -print
> [ successfully returns all *.pdf {lower case only} files in the subject
> directory ]
> C:> gnufind . -name *.PDF -print
> [ successfully returns all *.pdf {upper case only} files in the subject
> directory ]
>
> I'm pretty sure that Cygwin 'find' does NOT try to emulate shell globbing the
> way 'ls' does, so it makes sense that this works, and it supports the theory
> that something weird is going on between how Cygwin does shell expansion when
> under Windows CMD vs. when fully within the Cygwin environment (under bash
> where of course bash is doing the shell expansion, and ls or other Cygwin
> commands don't have to).
>
> Does any of this help pinpoint the problem further?
>
> thanks again,
> -Jay
>
> -Original Message-
> From: Paul Moore
> Sent: Sunday, 22 March 2020 20:09
> To: Jay Libove
> Cc: cygwin@cygwin.com
> Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No
> such file or directory" in Windows CMD shell, but works okay in bash
>
> Is this because cygwin globbing is (by default) case sensitive? You could set
> the CYGWIN environment variable to "glob:ignorecase" to get case-insensitive
> behaviour.
>
> Paul
>
> On Sun, 22 Mar 2020 at 17:52, Jay Libove via Cygwin wrote:
> >
> > I've never seen this before.
> > In a Windows CMD shell, Cygwin shell expansion, for example:
> > ls *.pdf
> >
> > returns:
> > ls: cannot access '*.PDF': No such file or directory (Indeed, any
> > Cygwin shell expansion, when executed from within Windows CMD,
> > produces this error. See below)
> >
> > ls *someotherwildcard* (that matches the same .pdf files) DOES return the
> > expected file list.
> >
> > Example:
> >
> > C:> DIR *.pdf
> > Volume in drive C is C
> > Volume Serial Number is 8674-712A
> >
> > Directory of C:\Temp
> >
> > 22/03/2020 18:30 1.675.954 test.pdf
> > XX/XX/ XX:XX {Any many other .pdf files}
> >
> > Yet:
> >
> > C:> ls *.pdf
> > ls: cannot access '*.pdf': No such file or directory
> >
> > And:
> > C:> bash
> > user@hostname /cygdrive/C/Temp/test
> > $ ls *.pdf
> > A.pdf
> > B.pdf
> > {etc}
> >
> > And, not ALL of the *.pdf files in the particular directory where I've
> > encountered this trigger the problem...
> >
> > C:> ls N*.pdf
> > N.pdf
> >
> > C:> ls A*.pdf
>
Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash
On Sun, 22 Mar 2020 at 19:11, Marco Atzeri via Cygwin wrote: > any reason for NOT using a cygwin shell ? Many reasons. But that's not relevant to this thread, is it? (Note: I'm not the OP, just an interested contributor to the thread). I'm happy to elaborate if you want, but I suggest we do it under a different subject line. Paul -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash
Is this because cygwin globbing is (by default) case sensitive? You
could set the CYGWIN environment variable to "glob:ignorecase" to get
case-insensitive behaviour.
Paul
On Sun, 22 Mar 2020 at 17:52, Jay Libove via Cygwin wrote:
>
> I've never seen this before.
> In a Windows CMD shell, Cygwin shell expansion, for example:
> ls *.pdf
>
> returns:
> ls: cannot access '*.PDF': No such file or directory
> (Indeed, any Cygwin shell expansion, when executed from within Windows CMD,
> produces this error. See below)
>
> ls *someotherwildcard* (that matches the same .pdf files) DOES return the
> expected file list.
>
> Example:
>
> C:> DIR *.pdf
> Volume in drive C is C
> Volume Serial Number is 8674-712A
>
> Directory of C:\Temp
>
> 22/03/2020 18:30 1.675.954 test.pdf
> XX/XX/ XX:XX {Any many other .pdf files}
>
> Yet:
>
> C:> ls *.pdf
> ls: cannot access '*.pdf': No such file or directory
>
> And:
> C:> bash
> user@hostname /cygdrive/C/Temp/test
> $ ls *.pdf
> A.pdf
> B.pdf
> {etc}
>
> And, not ALL of the *.pdf files in the particular directory where I've
> encountered this trigger the problem...
>
> C:> ls N*.pdf
> N.pdf
>
> C:> ls A*.pdf
> ls: cannot access 'A*.pdf': No such file or directory
>
> Nor do all directories containing .pdf files produce this. Of the many
> thousands of files and directories that I have, only some produce this
> problem.
> In others, ls *.pdf works perfectly in Windows CMD.
>
> I've looked at the Windows ATTRIB and CACLS of the files in directories where
> this problem occurs.
> They're all the same. That is, uniform across all files and directories.
> Nothing interesting.
>
> It's not just 'ls':
>
> C:> cat *.pdf
> cat: '*.pdf': No such file or directory
>
> So, it appears to be Cygwin shell expansion, when executed under Windows CMD,
> which is provoking this strange behavior.
> Any ideas what could be causing this, and how to solve it?
>
> many thanks,
> Jay
>
> --
> Problem reports: https://cygwin.com/problems.html
> FAQ: https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Is Cygwin 3.1.X Stable Enough to Use?
I had the same issue and it was fixed by 3.1.4, so yes upgrading was likely the fix. Paul On Fri, 21 Feb 2020 at 09:41, Takashi Yano wrote: > > On Thu, 20 Feb 2020 21:47:25 -0500 > Lee wrote: > > On 2/20/20, Lee wrote: > > > I'll try backing out the registry change & see if it still happens. > > > > It doesn't happen now. > > > > I deleted HKEY_CURRENT_USER\Console\VirtualTerminalLevel > > rebooted > > deleted all the .o files under /source/tidy & rebuilt > > The output of cmake looks normal > > > > I updated cygwin this morning: > > 2020/02/20 07:49:28 Augmented Transaction List: > > 2020/02/20 07:49:280 install cygwin 3.1.4-1 > > 2020/02/20 07:49:281 erase cygwin 3.1.2-1 > > 2020/02/20 07:49:282 install cygwin-devel 3.1.4-1 > > 2020/02/20 07:49:283 erase cygwin-devel 3.1.2-1 > > > > is it possible that fixed it? > > I am not sure. In my environment the problem does not occur > even with cygwin 3.1.2. Therefore, the cause cannot be identified. > > -- > Takashi Yano > > -- > 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 > -- 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: CYGWIN env variable - glob option
Some further investigations. 1. I missed the comment "default is set". So setting CYGWIN=glob is irrelevant. I may still want to set CYGWIN=glob:ignorecase, but that's a separate matter. 2. With forward slashes, globbing works as expected: E:\Utils\Cygwin64\bin\echo E:/Work/Scratch/m*.py E:/Work/Scratch/markov_pmf.py E:/Work/Scratch/monopoly.py However, with backslashes it does not: >E:\Utils\Cygwin64\bin\echo E:\Work\Scratch\*.py E:\Work\Scratch\*.py I can understand that the conflict between Windows using backslash as a directory separator and Unix using it as an escape character makes for a difficult problem, but nevertheless, the current behaviour is problematic for me (I won't say "wrong", because clearly plenty of people are fine with it, but it doesn't suit my use case, and I don't know if there's any setting I can use to improve things). Basically my issue is that I want to use cygwin from a Windows shell (powershell). I do *not* run cygwin commands from the cygwin shell - I am very familiar with, and comfortable in, powershell, but I do need Unix-like commands like grep, diff, etc, and cygwin provides the most reliable forms of those commands (good Unicode support, no weird bugs or porting glitches...) I routinely tab-complete directory names, with things like "grep so*.py" which autocompletes on tab to "grep .\sources\" and then I add "*.py". So it's fairly important for me that backslash-separated pathnames work. I don't know how unusual this is - I hear many people talking about using cygwin tools to get Unix-like utilities on Windows, but I don't know if the common use is via a cygwin shell (with a full Unix experience) or mixing Cygwin into a Windows shell like I do. If cygwin isn't intended to fit seamlessly into this use case, then that's fine - I'll just need to find an alternative way of getting Unix-like commands (maybe go back to mingw-compiled versions, and accept their limitations). But if there *is* a way to get things to work for my situation, I'd be disappointed if I missed it :-) If there *isn't* an option like that, is it something that could be added to the existing globbing code? I've never contributed to cygwin, but how easy would such a change be? Paul On Wed, 19 Feb 2020 at 16:46, Paul Moore wrote: > > I'm not sure if I'm misunderstanding the documentation of the "glob" > option in the CYGWIN environment variable. I have (this is under > Powershell Core 7.0.0-rc2): > > $env:CYGWIN="glob:ignorecase winsymlinks:native" > > if I then try to grep in a file that exists, using wildcards to > specify it, I get > > > C:\Utils\Cygwin64\bin\grep.exe . C:\Work\Scratch\mkpip*.ps1 > /usr/bin/grep: C:\Work\Scratch\mkpip*.ps1: No such file or directory > > Using echo as a (presumably) simpler test case: > > >C:\Utils\Cygwin64\bin\echo.exe C:\Work\Scratch\*.ps1 > C:\Work\Scratch\*.ps1 > > >C:\Utils\Cygwin64\bin\ls.exe -l C:\Work\Scratch\ > total 1121 > -rwxr-xr-x 1 Gustav Gustav 1144832 Feb 17 15:15 DigraphMgr.exe > -rw-r--r-- 1 Gustav Gustav 172 Jan 23 10:37 mkpipclone.ps1 > > I thought that the glob option resulted in glob expansion being done > before the args are passed to the grep command, so my expectation was > that this would work. > > This is with the very latest cygwin DLL - 3.1.4-1. I tried downgrading > to 3.1.2 (the earliest the installer offered) but that was no > different. The odd thing is that I thought I'd tested this on anther > machine, but now I can't get it to work as I expect :-( > > Am I doing something wrong? Or are my expectations incorrect? I need > to work with "native" backslash-delimited path names, because that's > how my shell autocompletes directory names, and patching them up with > forward slashes isn't really an option for me. > > Paul -- 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
CYGWIN env variable - glob option
I'm not sure if I'm misunderstanding the documentation of the "glob" option in the CYGWIN environment variable. I have (this is under Powershell Core 7.0.0-rc2): $env:CYGWIN="glob:ignorecase winsymlinks:native" if I then try to grep in a file that exists, using wildcards to specify it, I get > C:\Utils\Cygwin64\bin\grep.exe . C:\Work\Scratch\mkpip*.ps1 /usr/bin/grep: C:\Work\Scratch\mkpip*.ps1: No such file or directory Using echo as a (presumably) simpler test case: >C:\Utils\Cygwin64\bin\echo.exe C:\Work\Scratch\*.ps1 C:\Work\Scratch\*.ps1 >C:\Utils\Cygwin64\bin\ls.exe -l C:\Work\Scratch\ total 1121 -rwxr-xr-x 1 Gustav Gustav 1144832 Feb 17 15:15 DigraphMgr.exe -rw-r--r-- 1 Gustav Gustav 172 Jan 23 10:37 mkpipclone.ps1 I thought that the glob option resulted in glob expansion being done before the args are passed to the grep command, so my expectation was that this would work. This is with the very latest cygwin DLL - 3.1.4-1. I tried downgrading to 3.1.2 (the earliest the installer offered) but that was no different. The odd thing is that I thought I'd tested this on anther machine, but now I can't get it to work as I expect :-( Am I doing something wrong? Or are my expectations incorrect? I need to work with "native" backslash-delimited path names, because that's how my shell autocompletes directory names, and patching them up with forward slashes isn't really an option for me. Paul -- 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: Cygwin programs display output incorrectly when run under conemu
Thank you. That explains the issue for me very well. Paul On Mon, 17 Feb 2020 at 01:07, Dr Hartmut Bartels wrote: > > I had the same issue and got answer from Takashi Yano > https://cygwin.com/ml/cygwin/2020-01/msg3.html > > My workareound is > using version ConEmuPack.170807.7z. This works > together with cygwin 3.1.2-1. Versions of Comemu greater 170807 won't. > > Same for cmder, if replacing conemu with version 170807. > > Hartmut > > Am 16.02.2020 um 13:22 schrieb Paul Moore: > > This issue has also been reported to the ConEmu tracker as > > https://github.com/Maximus5/ConEmu/issues/2059. > > > > If I run a cygwin command (for example ls, or for a simpler example, > > "printf hello\nthere", although the latter needs care to get the > > correct level of \n escaping :-)) newlines are displayed by the text > > moving down a line, but *not* returning to the left hand margin. > > > > An example, running in Powershell as my shell: > > > >> E:\Utils\Cygwin64\bin\printf.exe hello\nthere > > hello > > there > > > > This behaviour is present with the latest version of cygwin1.dll, as > > well as with the 20200212 snapshot. It is not present if I replace the > > Cygwin dll with version 3.0.7-1. > > > > The problem does not appear with a standard cmd.exe terminal (standard > > Windows console host) or the new Windows Terminal application. I > > understand that ConEmu handles the console management differently > > "behind the scenes" to present a GUI front end, but I don't know > > enough about the internals to know how it does that. > > > > I can work around the issue by pinning to cygwin 3.0.7-1, but it's > > obviously not ideal. I have been unable to find any details as to what > > changed between cygwin 3.0.7-1 and the next version to help me track > > down the issue any more specifically. > > > > There are some notes at https://conemu.github.io/en/CygwinMsys.html > > that I've read, but to be honest I don't entirely understand. I did, > > however, confirm that this issue doesn't occur in a standard `cmd` > > window (and I added that information to the ConEmu issue report). > > > > Any information that would help to pin down the cause of this problem > > would be very much appreciated. > > > > Paul > > > > -- > > 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 > > > > -- > -- > Dr.-Ing. Hartmut Bartels > dr.hartmut.bart...@gmail.com > dr.hartmut.bart...@t-online.de > -- > > -- > 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 > -- 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
Cygwin programs display output incorrectly when run under conemu
This issue has also been reported to the ConEmu tracker as https://github.com/Maximus5/ConEmu/issues/2059. If I run a cygwin command (for example ls, or for a simpler example, "printf hello\nthere", although the latter needs care to get the correct level of \n escaping :-)) newlines are displayed by the text moving down a line, but *not* returning to the left hand margin. An example, running in Powershell as my shell: >E:\Utils\Cygwin64\bin\printf.exe hello\nthere hello there This behaviour is present with the latest version of cygwin1.dll, as well as with the 20200212 snapshot. It is not present if I replace the Cygwin dll with version 3.0.7-1. The problem does not appear with a standard cmd.exe terminal (standard Windows console host) or the new Windows Terminal application. I understand that ConEmu handles the console management differently "behind the scenes" to present a GUI front end, but I don't know enough about the internals to know how it does that. I can work around the issue by pinning to cygwin 3.0.7-1, but it's obviously not ideal. I have been unable to find any details as to what changed between cygwin 3.0.7-1 and the next version to help me track down the issue any more specifically. There are some notes at https://conemu.github.io/en/CygwinMsys.html that I've read, but to be honest I don't entirely understand. I did, however, confirm that this issue doesn't occur in a standard `cmd` window (and I added that information to the ConEmu issue report). Any information that would help to pin down the cause of this problem would be very much appreciated. Paul -- 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: Can't compile port qtermwidget
On 2020-02-10 9:55 a.m., Eliot Moss wrote: I wonder ... are there relevant ./configure options? EM I finally managed to dig to the bottom of this one, and sure enough it was a simple goof on my part. qtermwidget has a dependency on 'lxqt-build-tools' which includes cmake modules that provide some of the compiler flags. It turns out I had a local build of this package (of a more recent version) installed to /usr/local. Removing the local install and installing the cygwin lxqt-build-tools package instead, solved the problem. -- 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
X11 crashed immediately
Both Windows start links XWin Server and User script flash something on = the screen very very briefly and immediately close. startxwin from Cywin64 Terminal hangs without starting the Xserver. The Surface Go hardware specs which say the hardware and OS are 64 bit. (control panel settings about) cygcheckout (can’t get the list to accept as an attachment) shows: Windows 10 Home Ver 10.0 Build 17763 Path: . C:\cygwin64\home\phenk\bin C:\cygwin64\bin C:\cygwin64\usr\local\bin C:\cygwin64\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Windows\System32\OpenSSH C:\Users\phenk\AppData\Local\Microsoft\WindowsApps C:\cygwin64\bin\usr There is no C:\Windows\system64 Should I abandon home and go pro? Should I use 32bit cygwin? Thanks Paul -- 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: Can't compile port qtermwidget
On 2020-02-09 5:18 p.m., Eliot Moss wrote: I am not Qt savvy, but I can think of two generic things to check: - The Qt version in the cygwin libraries you have, versus what qtermwidget expects. - The version of the C compiler (gcc keeps evolving, and that sometimes breaks things). Maybe there is info on the web about Qt issues with various version of gcc. Thanks Eliot. The package works with the current Qt libs so I'm working under the assumption that the Qt version is Ok. I've figured out that if -DQT_NO_CAST_FROM_ASCII and -DQT_NO_CAST_TO_ASCII are removed from the compile directives, the situation improves drastically (at least on the first file I tried to compile manually, the number of compile errors goes from dozens to zero). But, I don't know why Cmake is adding those directives. -- 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
KDE Desktop
Hi everyone, I am trying to get the KDE plasma desktop running. I've installed xorg-server and plasma-desktop and can get simple gui apps running (e.g. gvim). When I try to run the plasma desktop (from "Plasma" icon installed in the windows start menu), the KDE logo appears against a black blackground for a while and then disappears, but then it eventually disappears and the window is left blank -- nothing more happens (and I have been patient to the tune of at least an hour). Any suggestions for things to try, to try to get this to work? -- 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: package cygwin-d-... case sensitivity problems --
--The NAME section line for the jN.3 man page is jN, jNf, yN, yNf, j0, j0f, j1, j1f, jn, jnf, y0, y0f, y1, y1f, yn, ynf - Bessel functions In a quick perusal of the available Cygwin math functions, I could find no available function with the first four names above although a C call to jN() does link successfully. In addition, the man page itself does not explicitly describe those four. Again, a quick google internet search did not find jN although I did find Jn. My original "simplest solution" would not work. New suggestion: Rename the jN.3 file bessel.3 and replace the first four names in the roff source file with bessel. -- Thanks, --Paul Townsend From: Townsend, Paul Sent: Tuesday, June 18, 2019 1:46:20 PM To: cygwin@cygwin.com Cc: Townsend, Paul Subject: package cygwin-d-... case sensitivity problems -- The cygwin-doc-... package has several problems in at least the /usr/share/man/man3 directory where multiple file names differ only in case, i.e., the tar file contains, in this order, usr/share/man/man3/jN.3.gz usr/share/man/man3/jn.3.gz The jN.3.gz file contains the roff text and the jn.3.gz file contains a roff .so directive pointing at jN.3. The file that ends up in man3 is jn.3.gz and jN.3.gz disappears. The simplest solution would be to just remove jn.3.gz and similar .so files from the tarball. This would at least allow the roff text files to exist. -- Thanks, --Paul Townsend FMI - where was the tarball created? It certainly was not on a computer with Windows and case insensitivity. -- 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
package cygwin-d-... case sensitivity problems --
The cygwin-doc-... package has several problems in at least the /usr/share/man/man3 directory where multiple file names differ only in case, i.e., the tar file contains, in this order, usr/share/man/man3/jN.3.gz usr/share/man/man3/jn.3.gz The jN.3.gz file contains the roff text and the jn.3.gz file contains a roff .so directive pointing at jN.3. The file that ends up in man3 is jn.3.gz and jN.3.gz disappears. The simplest solution would be to just remove jn.3.gz and similar .so files from the tarball. This would at least allow the roff text files to exist. -- Thanks, --Paul Townsend FMI - where was the tarball created? It certainly was not on a computer with Windows and case insensitivity. -- 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: sshd problem on WS2008R2 64bit
On Wed, Mar 06, 2019 at 03:44:36PM -0800, Stephen Paul Carrier wrote: > PW=`dd if=/dev/random bs=15 count=1 | base 64` That should be 'base64' of course, without the space. --S -- 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: sshd problem on WS2008R2 64bit
On Wed, Mar 06, 2019 at 02:24:59PM -0700, Bill Stewart wrote: ... > For my part, I'm writing a PowerShell script that does the following: > > 1) Create a local user account > 2) Grant it SeBatchLogonRight > 3) Create a scheduled task for it Powershell is probably more elegant if you're familiar with it, but I found this bash sequence that does the trick: - PW=`dd if=/dev/random bs=15 count=1 | base 64` net user s4udummy /add net user s4udummy $PW wmic USERACCOUNT WHERE NAME=\'s4udummy\' SET PasswordExpires=FALSE /usr/bin/editrights -u s4udummy -a SeBatchLogonRight schtasks /create /tn wake-s4u /sc ONSTART /ru s4udummy /rp $PW \ /tr '"$SYSTEMROOT"\\System32\\cmd.exe /c exit' sc config cron depend= Schedule - I added the last statement, to make cron dependent on the Task Scheduler, because my crontabs use '@reboot' and I am worried about cron trying to spawn an important job before the Task Scheduler has a chance to fix seteuid(). The dependency isn't logically sufficient as wake-s4u job needs some time to finish. But its working so far. I can configure cron to start with a delay should Task Scheduler ever lose the race. Thanks everyone for quick attention to this problem and the workaround! --Stephen -- 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: sshd permits logon using disabled user?
On Fri, Jan 25, 2019 at 08:34:09AM -0700, Bill Stewart wrote: > On Fri, Jan 25, 2019 at 3:36 AM Stefan Baur wrote: > > > Not on Linux (and possibly other Unices). There, it's perfectly valid > > to disable an account's password login (both locally and remote), but to > > at the same time allow ssh key file based logins for the same account. > > But disabling _password login_ is an entirely separate issue from > disabling _the account itself_. > > Before the fix, it was possible to log on to sshd using a disabled (or > locked) account. > > There should be _no_ scenario where it is possible to log on using a > disabled/locked account. There are different paths to access and to completely disable the account you need to close all of them. There are many reasons to disable some paths without disabling all paths and converting the switch that can disable one path to a switch that will disable all paths will break some setups and be less flexible. (As Stefan Baur is pointing out effectively.) To disable ssh logins really, instead of changing the way Cygwin works for everyone, you could do what UNIX/Linux admins do, something like moving the user .ssh folder to .ssh.disabled. Stephen Carrier Systems Administrator BEAR (Berkeley Evaluation & Assessment Research) Center Graduate School of Education University of California, Berkeley http://BEARcenter.Berkeley.EDU/ carr...@berkeley.edu -- 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
Hi Cygwin
-- 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
Semantic difference with/without CYGWIN=winsymlinks:nativestrict
Attempts to make symlinks are handled differently depending on (1) whether or not the target file pre-exists and (2) whether or not CYGWIN=winsymlinks:nativestrict is exported. Actually, 'ln' seems to require the pre-existence as if it were a hard link attempt when CYGWIN is defined. FWIW - 'ln' on Ubuntu 18.04 on WSL (Windows Subsystem for Linux) allows the target to be nonexistent. The following is a very simplistic example: $ unset CYGWIN $ rm a b $ ln -s a b $ ls -l a b ls: cannot access 'a': No such file or directory lrwxrwxrwx 1 aab None 1 Sep 6 03:45 b -> a <=<=< not a "real" Windows type symlink $ export CYGWIN=winsymlinks:nativestrict $ rm a b $ ln -s a b ln: failed to create symbolic link 'b': No such file or directory $ rm a b rm: cannot remove 'a': No such file or directory rm: cannot remove 'b': No such file or directory $ touch a $ ln -s a b $ ls -l a b -rw-r--r-- 1 aab None 0 Sep 6 03:55 a lrwxrwxrwx 1 aab None 1 Sep 6 03:55 b -> a $ rm a b Found above when I downloaded the source for 'bash-4.4' and 'cygport'/'tar' attempted to make the symlink bash-4.4/ChangeLog -> [bash-4.4/]CWRU/changelog which did not yet exist. The error message is a bit confusing but it implies that the destination must pre-exist in order for the symlink to be made. FWIW - With CYGWIN exported as shown above, 'ln' does create real symlinks as verfied by Windows 10 File Explorer. --Thanks -- 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: Cygwin X11 Server slow performance
20 years ago Linux cult members were using the same "blame-the-user"-type arguments. Nothing has changed. I don't use Emacs. I only gave it as an easily-testable example. Try: apt-get install xemacs ; export DISPLAY=windows.mylan:0.0 ; xemacs Professionally, I have been a C++ developer for 20 years, and I am also a published author: https://www.amazon.com/LINUX-Rute-Users-Tutorial-Exposition/dp/0130333514 I don't need to do ANY analysis or tests to see that the Cygwin and Mingw X Servers have abhorrent latency problems: you press a key and you wait 0.25 seconds for the page to render. That's like the speed of a page render over 9600 baud terminal. X Servers were NEVER this slow even in the 1990s. Why would I sit and do a mathematical analysis, when I can simply uninstall it and install something that actually works??? Why would I waist my time trying to fix the problem, when cygwin mailing list respondents refuse to admit the problem exists??? You are like a Flat-Earther the way you argue. Paul On 6/5/18, L A Walsh wrote: > Paul Sheer wrote: >>> Maybe you aren't familiar with 'X'. X is just a graphical >>> transport. It doesn't have menus unless some other program puts them >>> up. >>> Try 'X' on linux -- running it from startX from a console and see >>> how easy it is to use. >>> >> >> >> NetSarang commercial X server has configuration menus to set keyboard >> mappings, cut-paste behavior, and various other settings in a user >> friendly manner. It has orders of magnitude faster performance in a >> side-by-side comparison using XEmacs Motif as a test application >> displayed remotely over a 1GB LAN. > --- > That's fine, but how much does NetSarang cost for 10-15 years > of commercial support & upgrades? > > I use Gvim over a Gtk interface. The fact that you are > comfortable with a 20 yr-old graphical interface, that was only > reasonably supported by commercial Unix vendors puts you in a > different class of users -- which was why I suggested an Apple > based OS in the first place. > > >> But that fact that you are using the reason "X is just a graphical >> transport" as an excuse makes me realize it is impossible to have a >> conversation with you. > --- > From my perspective, that's what it is, not too many > programs are built on the Xlib et al. widget set. I tune my programs > and I/O more for file I/O and know my toolsets enough to know that > they don't do with small packets, but had file I/O tuned at > 125megaB (mega=10**6) writes and 119megaB reads over a 1GB LAN > and now get 600+MB(M=2**20) reads and 275+ writes over a 8Gb LAN > (10 in name, but lose 20% to bus speed). My speeds now, in file > I/O and in gvim are limited by CPU speed as Gvim does near full > syntax parsing for error and color display. > > Realize though, that the fact that you prefer a commercial > emacs version to a free X11+gtk Gvim sorta puts you more in a > commercial apple class which is another reason I pointed at > Apple based computers. Also, even the fact that you prefer emacs > + motif...makes it less likely you'll be happy with something > that requires more work on the part of the user to tune for the > OS + hardware; again=> apple. > > I hope you appreciate my input, it certainly wasn't from a fanboy > of any of the OS's, point of view, but you've indicated you want > Cadillac features and support. I suggest and hope you find what > you are looking for. > > > (M=2**30) writes with > -- 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: Cygwin X11 Server slow performance
> Maybe you aren't familiar with 'X'. X is just a graphical > transport. It doesn't have menus unless some other program puts them up. > Try 'X' on linux -- running it from startX from a console and see > how easy it is to use. > NetSarang commercial X server has configuration menus to set keyboard mappings, cut-paste behavior, and various other settings in a user friendly manner. It has orders of magnitude faster performance in a side-by-side comparison using XEmacs Motif as a test application displayed remotely over a 1GB LAN. But that fact that you are using the reason "X is just a graphical transport" as an excuse makes me realize it is impossible to have a conversation with you. Paul -- 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: Cygwin X11 Server slow performance
> > Cygwin/X is most definitely being used, and this might help: > > https://x.cygwin.com/docs/ug/using-shared-memory.html > Being used? I find that very difficult to believe. There are a large number of usability problems I have found and I have only been using Cygwin for a couple of hours. It's does not seem ready for release yet IMO. 1. There seems no way to map particular important keys. For instance Left-Alt-Tab should be configurable to either Windows or X11 depending on the users preference, and this configuration should be available in a menu somewhere easy to find -- but it has no configuration menus on the top bar like normal applications. 2. it is extremely difficult to work out that "C:\cygwin64\bin>XWin.exe -ac -listen tcp" is the appropriate command to type to get the server to serve a remote Linux machine. This seems like a common use case -- so why "hide" this information? 3. Forgets that you have your mouse button held down if you drag past the edge of the X screen. It should not let your mouse cursor out the X screen when you are dragging. 4. Is there no option like XWin.exe -ac -listen 10.12.21.0/24 to restrict connections to a particular network?? This seems very easy to implement and solves the security problem. It might be in a menu also. 5. The performance issue is not related to the shared memory problem. My text editor has multiple ways of rendering 8x13bold (font-struct font-set and pixmap) and they are all slow. XMing is also slow (I have notified Colin Harrison but even after a year he cant fix it). This latency may be because you are not using Windows accelerated rectangle copies, or it may be because you have not disabled the Nagle algorithm for latency. 6. cygserver-config does not work. It gives: [[[ psheer@psheer-HP ~ $ cygserver-config Overwrite existing /etc/cygserver.conf file? (yes/no) yes Generating /etc/cygserver.conf file chown: changing ownership of '/etc/cygserver.conf': Permission denied Warning: The following function requires administrator privileges! Do you want to install cygserver as service? (Say "no" if it's already installed as service) (yes/no) yes /usr/bin/cygrunsrv: Given path doesn't point to a valid executable Try `/usr/bin/cygrunsrv --help' for more information. Installation of cygserver as service failed. Please check the error messages you got. They might give a clue why it failed. A good start is either you don't have administrator privileges or a missing cygrunsrv binary. Please check for both. ]]] 7. Surely the above program can check if it is a privilege problem or not and simply tell you? Why should I have to read through documentation to enable a simple "checkbox" feature when it can only be On or Off and there are no other options??? 8. cygwin seems to have the concept of an administrator, but there is no root user or way to switch to a root user using su. If these things exist, then they should be there by default and work as default so as not to require the user read documentation. Is my default user the administrator? It should be -- it is a home PC. I can't even tell what the intended behavior is. It keeps asking me for a password for psheer but I have never set a password on this PC. 9. There is no package management that works properly. The install program setup-x86_64.exe seems to re-download things that are already downloaded. It is kludgy and everything is ambiguous. It seems unclear what is a label telling you the state, or a button telling you to switch to a state. Surely it is easy to make a Gtk or Qt interface for this package manager? How do you know what a "minimal" set of packages is? Do I have to install everything? If I install everything does it cache what it has downloaded so as not to download everything again? Normal windows packages do not require you ask any of these questions -- the install interface makes it clear. 10. After trying to install more packages I now get: "The procedure entry point __memcpy_chk could not be located in the dynamic link library cygwin1.dll" 11. Surely the Start menu should have a cygwin-packages menu item to manage package, get dependencies correct, and verify the integrity of an installation. 12. Your documentation is extremely strange. For instance you have "https://x.cygwin.com/docs/ug/using-clipboard-integration.html";. Why would any user ever read about clipboard integration??? The clipboard problems and the relationship between X11 and Windows have been solved many years ago. This is evident from the fact that Ubuntu, when installed under Oracle Virtual box, does Copy-n-Paste between Gtk and Windows and Unicode copy-paste even works perfectly in both directions. So copy and paste should "just work". Any configuration should be in menus anyway. 13. Why do some binaries run on the command line and do nothing and show no error??? Unix never does this. I hope this all helps. I'll be uninstalling cygwin now because I can't waist any more time on it.
Cygwin X11 Server slow performance
Hi, I am trying to use the Cygwin X11 Server on Windows 64-bit as follows: C:\cygwin64\bin>XWin.exe -ac -listen tcp (Note this is on a private LAN without Internet access.) The X Server renders perfectly well and my favorite applications do start up and run. However performance is extremely slow -- it is slightly too slow to be usable. For instance I tried some graphical text editors, and a [PageDown] press take 0.25 seconds to render: Whereas on a commercial X Server running side-by-side on the same Windows desktop renders in <0.03 seconds. I am a bit confused if this is intended this way: i.e. is this just a demonstration of the capabilities of CygWin, or is it actually being used by anyone? I ask because there are no reports of anyone finding the X Server slow, yet the software has been many years in release. Thanks Kind regards Paul -- 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
subscribe paulsh...@gmail.com
-- 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: msmtp depends on Gnome!?
On Fri, Mar 30, 2018 at 02:50:36AM +0300, Andrey Repin wrote: > Greetings, Stephen Paul Carrier! > > > My use case is a sendmail replacement (MTA) to use with cron. > > ssmtp > > > ssmtp does this poorly (and hasn't been maintained since 2009). > > Please clarify. What does it not do for you, and what needs maintenance? It seemed to be losing messages. Maybe that's what non-queueing MTA's do if the server doesn't respond. But there was no indication of a specific error other than the nonzero exit status. I didn't mean to complain about ssmtp so much as switch to something that implements the same basic idea but is currently maintained. Maybe switching will fix the problem, maybe it won't. Still worth changing, I think. And msmtp is a Cygwin package and should have realistic dependencies. I had recently discovered this page: https://wiki.archlinux.org/index.php/SSMTP, which has the best documentation I have seen for ssmtp. Still, the page itself suggests using msmtp instead. Jon Turney reports (in this list) that the msmtp dependencies have been fixed and I confirm that they are. Thanks to all! Stephen Carrier -- 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: msmtp depends on Gnome!?
On Thu, Mar 29, 2018 at 03:24:50PM -0400, Will Parsons wrote: > On Wednesday, 28 Mar 2018 9:40 PM -0400, Brian Inglis wrote: > > On 2018-03-28 15:50, Stephen Paul Carrier wrote: > >> msmtp is billed as a light-weight SMTP client and I would like to use > >> it with cron instead of ssmtp. > >> What's not light-weight is its dependency on libgnome-keyring0 which > >> has more dependencies that eventually bring in Gnome. This is for a > >> headless workstation. > >> Is it possible to remove or replace this dependency so that msmtp can > >> be installed without enlarging the size of the install by such a factor? > > > > Look at the other packages under the Mail category e.g. email, mailutils, > > nmh. > > I've poked around with some of them, and most are pretty easy to set up and > > use, > > depending on your requirements. > > That may be true, but it is still surprising that msmtp should depend > on libgnome-keyring0. I don't use msmtp under Cygwin, but I do under > FreeBSD, and under the latter platform, my version of msmtp seems to > depend on: > > bash-4.4.12_3 > ca_root_nss-3.36 > indexinfo-0.3.1 > gettext-runtime-0.19.8.1_1 > > This obviously will not translate directly into Cygwin, but it > certainly suggests that the OP's comment is justified. (I'll have to > admit, I don't know why even bash should be a dependency.) My use case is a sendmail replacement (MTA) to use with cron. I want to configure it to send correctly formatted e-mail to a smarthub. That is all I need. Cron expects something with sendmail-like commandline interface. ssmtp does this poorly (and hasn't been maintained since 2009). msmtp is reputed to do this also, more reliably, more flexibly, and had a new version released in 2016. I don't need a MUA client like email, nmh, or a local delivery agent like comes with mailutils. These are not sendmail workalikes. I understand that Gnome may include a library used by msmtp. Maybe that library could be packaged separately? It sort of defeats the purpose of providing light-weight network utility if a desktop needs to be installed just to get a miscellaneous library function. It is not even a graphical program. Also, maybe this dependency is just an oversight? Also, maybe libgnome-keyring0 is really standalone and doesn't actually depend on a desktop. Wherever this issue comes from it would be great and I would appreciate the effort if anyone can correct it. Thanks! Stephen Carrier -- 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
msmtp depends on Gnome!?
Dear cygwin people, msmtp is billed as a light-weight SMTP client and I would like to use it with cron instead of ssmtp. What's not light-weight is its dependency on libgnome-keyring0 which has more dependencies that eventually bring in Gnome. This is for a headless workstation. Is it possible to remove or replace this dependency so that msmtp can be installed without enlarging the size of the install by such a factor? Thanks! Stephen Carrier -- 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
Dear Applicant
Dear Applicant, We wish to inform you that your resume has been reviewed by the appropriate department throughly and you have been shortlisted for the position of an Administrative Assistant. You have been selected for an interview with us You are to create or use an existing gmail account (hangout) to proceed with the job and to know more about the company, locations, positions, pay scale and duties. You are to set up a screen name with Google Hangout messenger and add up the company's head of operation ID to your contact list, ID Google Hang Out ID ( paulsteward...@gmail.com ) and instant message him for an online interview/briefing exercise. You are to be available on Google Hangout for the interview (ASAP), Your swift and timely response matters to this position as well as the job interview. I wish you all the very best of luck in the interview. Please feel free to email Paul Steward for more details. Time: Asap Pay: $30 - $35 hourly Position: Administrative Assistant Venue: Google HangOut (Gmail IM) Best regard, Human Resources Department. -- 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
KtikZ port
Hi, When in Windows, I do my LaTeX work in Cygwin. I recently started using KtikZ[0] which I found is missing from the Cygwin ports repository even though it used to be there[1]. Any idea why it was not ported over? Can I help in any way? Thank you, Paul Irofti [0] -- http://www.hackenberger.at/blog/ktikz-editor-for-the-tikz-language/ [1] -- https://sourceforge.net/p/cygwin-ports/ktikz/ci/master/tree/ -- 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
[a tangent but hopefully not OT question] Re: Malwarebytes flags qdbusviewer-qt5.exe as Adware.Elex malware
On 03/19/2017 01:23 PM, René Berber wrote: On 3/19/2017 12:18 PM, Ed Koerber via cygwin wrote: It bears asking to be thorough... are we sure that the cygwin package has not been compromised somehow? You are correct in not taking unsubstantiated remarks as useful. We usually run the program in question through https://www.virustotal.com/ If several, reputable, scanners flag it as a virus, then its probably a virus. Hope this helps. Rene: I looked at https://www.virustotal.com/ and found it interesting. That being said, everything on it looked "pc" and "windows" except for one report of issues which seemed OS/Mac based. I went through all the documentation and tabs to other pages as best I could (including the FAQ). I could not get a clear answer as to whether this site handled any and all queries was platform agnostic or limited to Windows (and maybe OSX). I have to deal with Windows via Cygwin, OSX, and Centos/Fedora and can't figure out if I can send anything from any platform to this site. Thanks in advance for humouring my tangent within this same thread (I made sure I changed the subject to reflect the tangent) Paul -- 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: Issue with delayed process start and effect on Windows 10
Hello Barry, High Five to you! I do indeed have Rapport installed and it looks like it does not co-exist well with CYGWIN. I rebooted, stopped Rapport and then ran the script I have been trying to run for a day and it went through flawlessly at normal speed. It is very strange that 2 different applications that have nothing to do with each other can interfere with each other in this way. Once again thank you for taking the time to respond and also to the CYGWIN team for their time and suggestions. Paul Kitchen -Original Message- From: b...@theworld.com [mailto:b...@theworld.com] Sent: 02 February 2017 21:03 To: Paul Kitchen Cc: cygwin@cygwin.com Subject: Re: Issue with delayed process start and effect on Windows 10 I noticed almost exactly the same problem, I remember it was about 15 seconds per process, and traced it to IBM Rapport Trusteer (some sequence of words like that) banking app which some banks require be installed and running in order to login and view your account. All this seems somewhat better with a recent update to that app. If that may be the problem it's not enough to just use the app's "Rapport Manager" shutdown. I had to kill the manager also via the task manager before there was any change. And unless you do some heroics it will all start itself up at boot, it seems to be installed like a virus (usual MS tools can't seem to stop it from starting at boot.) It's not difficult to stop/restart the app when needed though is annoying as it requires jumping through a captcha, task manager, their manager, etc just to see one's bank balance. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com <http://s.bl-1.com/h/BmZ3xCN?url=http://www.TheWorld.com> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* -- 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: Issue with delayed process start and effect on Windows 10
Hi All, I have attached the cygcheck_output.txt file requested. I hope it helps. When I said that the process start delay is 20 seconds. It is precisely 20 seconds give or take a few milliseconds which seems to imply to me to be some kind of a timeout. Just to give more information: I am running CYGWIN on my laptop which does not form a part of any windows domain and is therefore not at any time connected to a DC. It is a personal WORKSTATION. The nsswitch.conf file contains : passwd: db group:db db_enum: cache builtin db_home: /home/%U db_shell: /bin/bash db_gecos: Paul Kitchen -Original Message- From: Marco Atzeri [mailto:marco.atz...@gmail.com] Sent: 02 February 2017 17:51 To: cygwin@cygwin.com Cc: pkitc...@talk21.com Subject: Re: Issue with delayed process start and effect on Windows 10 On 02/02/2017 16:24, Andrey Repin wrote: > Greetings, Paul Kitchen! > > To me it sounds you are using domain offline logon. > In any case, > >> Problem reports: http://cygwin.com/problems.html <http://s.bl-1.com/h/BmSrLxv?url=http://cygwin.com/problems.html> Hi Paul, specially we need a copy of the cygcheck.out to comment on your system status. Regards Marco Cygwin Configuration Diagnostics Current System Time: Thu Feb 02 19:51:46 2017 Windows 10 Professional Ver 10.0 Build 14393 Path: C:\cygwin64\usr\local\bin C:\cygwin64\bin C:\ProgramData\Oracle\Java\javapath C:\Program Files\AuthenTec TrueSuite C:\Program Files\AuthenTec TrueSuite\x86 C:\Program Files\Common Files\Microsoft Shared\Windows Live C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static C:\Program Files (x86)\Common Files\Roxio Shared\10.0\DLLShared C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared C:\Program Files (x86)\Sony\VAIO Startup Setting Tool C:\Program Files (x86)\Windows Live\Shared C:\PROGRA~1\DISKEE~1\DISKEE~1 C:\Program Files\Intel\WiFi\bin C:\Program Files\Common Files\Intel\WirelessCommon C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn C:\Program Files\Microsoft SQL Server\110\Tools\Binn C:\Program Files\Microsoft SQL Server\110\DTS\Binn C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\Common Files\Acronis\SnapAPI C:\Program Files\Calibre2 C:\Program Files (x86)\Common Files\Acronis\VirtualFile C:\Program Files (x86)\Common Files\Acronis\VirtualFile64 C:\Program Files (x86)\Skype\Phone C:\Program Files\Cloud Foundry C:\Program Files\Intel\WiFi\bin C:\Program Files\Common Files\Intel\WirelessCommon C:\Activator\activator-1.3.10-minimal\bin %USERPROFILE%\AppData\Local\Microsoft\WindowsApps Output from C:\cygwin64\bin\id.exe UID: 197609(Paul) GID: 197121(None) 197121(None) 197608(HomeUsers) 197622(mqbrkrs)197620(mqm) 197632(Ssh Users) 545(Users) 4(INTERACTIVE) 66049(CONSOLE LOGON) 11(Authenticated Users)15(This Organization) 113(Local account) 66048(LOCAL) 262154(NTLM Authentication)401408(Medium Mandatory Level) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS Here's some environment variables that may affect cygwin: USER = 'Paul' PWD = '/home/Paul' HOME = '/home/Paul' Here's the rest of your environment variables: USERDOMAIN = 'MY-VAIO' OS = 'Windows_NT' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' PROCESSOR_LEVEL = '6' PSModulePath = 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\;c:\Program Files (x86)\Microsoft SQL Server\110\Tools\PowerShell\Modules\' CommonProgramW6432 = 'C:\Program Files\Common Files' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' FP_NO_HOST_CHECK = 'NO' LANG = 'en_GB.UTF-8' TZ = 'Europe/Berlin' HOSTNAME = 'My-VAIO' PUBLIC = 'C:\Users\Public' OLDPWD = '/cygdrive/c/Users/Paul/Desktop' JD2_HOME = 'C:\Users\Paul\AppData\Local\JDownloader 2.0' USERNAME = 'Paul' JAVA_HOME = 'C:\Program Files\Java\jdk1.8.0_60' LOGONSERVER = '\\MY-VAIO' PROCESSOR_ARCHITECTURE = 'AMD64' LOCALAPPDATA = 'C:\Users\Paul\AppData\Local' COMPUTERNAME = 'MY-VAIO' FPS_BROWSER_APP_PROFILE_STRING = 'Internet Explorer' !
Issue with delayed process start and effect on Windows 10
Hi All, I am a newbie to Cygwin having downloaded it yesterday. I managed to install it after some time (for the reasons explained below) and brought up a Cygwin terminal. During a script run initiated in the Cygwin terminal, I noticed that after a very short while, the execution would slow down to a crawl. The script was running but in very slow motion. I looked at the sequence of events using a windows sysinternals tool and found that there is a delay in starting (forking?) a new command (e.g. ls) of precisely 20 seconds which is strange. The script runs normally but very very slowly. I noticed a side effect too. After the slowing down in Cygwin, certain windows apps behaved the same way as though there was cross contamination from Cygwin. Windows Task Manager takes about 40 second to appear and same for the Windows Command Window. Flash extension in the Chrome browser would continuously fail to start. To repair the situation I had to reboot. To make sure that Cygwin was not still active, I aborted all bash.exe processes that were running and the problem continued to persist. Is this a known problem? For me it makes Cygwin completely unusable which is a pity. Paul Kitchen -- 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
new setup.exe doesn't collapse package sets in full view.
I downloaded the new setup program (2.877, 32-bit) and ran it on a cygwin installation that hadn't been updated in over a year (2008R2). I first got the Pending view, OK, then switched to Full and found that the packages were not aggregated into tabs-- they were in one very long alphabetical list. I am wondering whether the more convenient tabbed view is still available and if others are also seeing this issue. I tried a different download source, same issue. I have tried with server that hadn't been updated in >1 year, and server that was updated last week. Same issue. Can the tabbed view be retained as an option, even for pre-existing installations? Thanks. Thanks, Stephen Carrier -- 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 names not meaningful enough
On Thu, Dec 01, 2016 at 11:37:41AM -0500, Ian Lambert wrote: > On December 1, 2016 8:54:57 AM EST, cyg Simple wrote: > > > > > >On 12/1/2016 8:25 AM, Vlado wrote: > >> On 1.12.2016 13:51, Eliot Moss wrote: > >>> I think that including the version of the setup program could be > >helpful > >>> - I tend > >>> to add it (renaming the file by hand). However, clearly we've lived > >>> with things this > >>> way for a long time ... > > > >More than a score years. > > > >> > >> I disagree. > >> I have a script to update Cygwin. This script checks for new version > >of > >> setup, downloads, verifies signature, etc. Things would become much > >more > >> complicated with variable setup file name. > >> Finally: Why should I care about the exact version number of setup? > >> Script makes backups of the old setup files like setup.exe.0001, > >0002, > >> ..., just for a cause, but never in the past I did have to looking > >for > >> the setup with exact version number. > >> > > > >The only reason would be if you had an older version of the .ini file. > >When the data prerequisites of the .ini file change there is a new > >version of setup to handle that. Right, and the way to learn if this is the case is to run setup. I learn that a new version is available by running the old version. Running setup is also the way to find out what is the version. I don't mind renaming the file myself, but would really appreciate any way to know from the cygwin.com front page exactly which version of the setup-*.exe is on offer. (The current version of Cygwin DLL is useful, but not the same thing.) Stephen Carrier -- 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: python 2.7.12 pip install with extensions fails with warning: "__BSD_VISIBLE" redefined
>> Hi - >> >> The newest version of cygwin with python 2.7.12-1 fails when pip >> installing packages that require compilation. For example, pycrypto >> fails: > >FWIW this patch to pycrypto also fixes it: > >https://git.sagemath.org/sage.git/tree/build/pkgs/pycrypto/patches/cygwin/disable-std-c99.patch?id=aaa9b7fc887b64ba1dba7cba16061f598a097b75 > >The problem only occurs when trying to build with the C99 standard if >Python itself was not. I fixed this issue by editing /usr/include/python2.7/pyconfig.h to comment out the second line of: /* Define on FreeBSD to activate all library features */ #define __BSD_VISIBLE 1 This seemed like the right thing to do since Cygwin isn't FreeBSD, and the problem went away. Is this an oversight in python-devel package? Issue doesn't occur in 32-bit version. Stephen Carrier Systems Administrator BEAR (Berkeley Evaluation & Assessment Research) Center Graduate School of Education University of California, Berkeley http://BEARcenter.Berkeley.EDU/ -- 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
Cygwin Xwin Windows 10 Trend Micro
Trend Micro support called me back about this issue. I spent some time with them on the phone, with the support engineer trying a few things. We ended up with a reinstall of the https://esupport.trendmicro.com/en-us/home/pages/technical-support/maximum-s ecurity/1112161.aspx hotfix, after which Cygwin-X runs fine, WITHOUT having the pause user mode checking turned on. The support engineer mentioned something about an update coming out *after* my previous post. Apparently I needed both the update and the hotfix to make things work. Hope this helps someone... Paul McKinley -- 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
Cygwin Xwin Windows 10 Trend Micro
I just upgraded to Windows 10 via fresh install, including a fresh install of Cygwin. I use Trend Micro antivirus. I had issues with the dash postinstall rebase operation which would hang, but figured out that it would work if I temporarily disabled Trend Micro. I couldn't get the X windows to work, not even with the entire Cygwin directory set to exempt in Trend Micro. So I did a support chat session with Trend Micro. They said to set the "Pause User Mode Hooking" - which works. You get to this setting by running the Trend Micro Diagnostic Toolkit, it's under the "Threats" tab. They also recommended a hotfix, see https://esupport.trendmicro.com/en-us/home/pages/technical-support/maximum-s ecurity/1112161.aspx but that didn't help. This issue has been sent to Trend Micro engineering for resolution. Supposedly. Meantime if you're having issues running Cygwin Xwin with Trend Micro installed, try enabling the "Pause User Mode Hooking" solution above. Hope this helps someone Paul McKinley -- 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
Unwanted disconnections of X clients - cygwin 64 - version 2.874
Hello, We use Cygwin for a few years to give access to linux servers to users from their windows PC. We use xlaunch to launch Xwin and open X11 remote sessions via XDMCP. Our linux server launches on Cygwin/X a client to let users authentificate themselves and open a session on the linux server. Once connected, gdm3 opens a session combining a set of clients and permitting the users to open the applications they need. This works correctly on several pc of our local network with various versions of cygwin, such as: - version 2.859 of cygwin (installation: 16/01/2015) - 32 bits - version 2.870 of cygwin (installation: 24/04/2015) - 64 bits With recent versions, at least 2.873 or 2.874, we observe that : - the login client is closed and relaunched every 2 to 5 minutes - the session, once opened, is closed and all clients killed every 2 to 5 minutes, independently of the activity of the user (he may work or not), as if the PC was disconnected. The login client is displayed again after each disconnection. Nothing abnormal appears in the log file of cygwin, nor in the windows events and errors files. On the linux server, some errors are notified in the .xsession-errors of the user: Fatal IO error 11 (Ressource temporairement non disponible) on X server x-session-manager[4139]: Gdk-WARNING: x-session-manager: Fatal IO error 11 (Ressource temporairement non disponible) on X server 147.100.68.164:0. (gnome-settings-daemon:4200): Gdk-WARNING **: gnome-settings-daemon: Fatal IO error 11 (Ressource temporairement non disponible) on X server 147.100.68.164:0. (gnome-terminal:4473): Gdk-WARNING **: gnome-terminal: Fatal IO error 11 (Ressource temporairement non disponible) on X server 147.100.68.164:0.0. Avertissement du gestionnaire de fenêtres : Erreur fatale d'E/S 11 (Ressource temporairement non disponible) sur le visuel « 147.100.68.164:0 ». g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Received signal:15->'Complété' (nm-applet:4254): Gdk-WARNING **: nm-applet: Fatal IO error 11 (Ressource temporairement non disponible) on X server 147.100.68.164:0. (gdu-notification-daemon:4257): Gdk-WARNING **: gdu-notification-daemon: Fatal IO error 11 (Ressource temporairement non disponible) on X server 147.100.68.164:0. (gnome-screensaver:4281): Gdk-WARNING **: gnome-screensaver: Fatal IO error 11 (Ressource temporairement non disponible) on X server 147.100.68.164:0. May be, on the linux server, the session manager fails to read or write something on the X server running on the PC or to receive some data he has asked, and decides to close the session. But what ? On the same PC, when I try to compare permissions on folders like /tmp, /tmp/.X11-unix, /var/run, /var/tmp, ..., between the recent version with disconnection problems and an older one without these problems, I notice many differences. But I don't know whether they are or not in relation with the problem and it doen't seem judicious to apply a few limited and punctual modifications, rather than a script rationally solving permission problems. I have not found on cygwin archives recent contributions about similar problems. Have someone met similar problems and found how to solve them ? Best regards, Jean-Paul Bouchet Institut National de la Recherche Agronomique - Centre de Provence, Alpes, Côte d'Azur UR 1052 <http://w3.avignon.inra.fr/gafl/en> - Génétique et Amélioration des Fruits et Légumes Domaine Saint-Maurice - CS 60094 - F-84143 Montfavet cedex - France E-mail : <mailto:jean-paul.bouc...@avignon.inra.fr> -- 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 of Cygwin 64 seems to freeze when executing /etc/postinstall/xlaunch.sh - version 2.874
Hello, May be is the value of PATH the problem? When I launch, by a double click on the bash.exe file, a cygwin bash shell (C:\cygwin64\bin\bash.exe) and I display $PATH, I don't find any cygwin directory in the list, but a list of windows directories: /cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem: ... So, when I execute in the cygwin bash shell the command '/bin/sh -x /etc/postinstall/xlaunch.sh.done', I get the same errors than those I get when I execute 'C:\cygwin64\bin\sh -x /etc/postinstall/xlaunch.sh.done' in the windows command interpreter: the command 'uname' is unknown. If I change the value of PATH with PATH=/cygdrive/c/cygwin64/bin:$PATH and export PATH, the execution of 'sh -x /etc/postinstall/xlaunch.sh.done' don't give any errors. What is the value of PATH when the installation executes the set of postinstall scripts ? Jean-Paul Bouchet On 03/06/2016 14:41, Jon Turney wrote: On 02/06/2016 17:22, Jean-Paul Bouchet wrote: Please find attached the script /etc/postinstall/xlaunch.sh and the output of its execution (file postinstall_xlaunch.txt). Thanks. I guess this doesn't reproduce the problem (freezing), as this is just what I would expect to see when running the script without the PATH set? Perhaps you could try again from a cygwin bash shell? -- 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 of Cygwin 64 seems to freeze when executing /etc/postinstall/xlaunch.sh - version 2.874
Hello,
Please find attached the script /etc/postinstall/xlaunch.sh and the
output of its execution (file postinstall_xlaunch.txt).
Thank you.
Best regards,
Jean-Paul Bouchet
On 02/06/2016 15:21, Jon Turney wrote:
On 31/05/2016 17:36, Jean-Paul Bouchet wrote:
I try to install cygwin 64 on a windows 7 PC in order to let users open
an X11 session via xlaunch on a linux server (gdm3).
I have selected only 3 components of X11 to complete the default
selection : xinit, xlaunch and Xorg server.
The installer seems to freeze when it executes
/etc/postinstall/xlaunch.sh.
Information about the progression of the installation is blocked during
several minutes with 99% Cygwin - Setup
If I don't cancel the installation, it seems to finish correctly.
17:36:33 running: C:\cygwin64\bin\bash.exe --norc --noprofile
"/etc/postinstall/xlaunch.sh"
17:55:47 Changing gid to Administrators
Ending cygwin install
Is it a normal behaviour ?
Thanks for reporting this problem.
No, this is not normal or expected.
Perhaps you could manually run the postinstall script with 'sh -x
/etc/postinstall/xlaunch.sh.done' to see where it is getting stuck?
C:\cygwin64\bin\sh -x /etc/postinstall/xlaunch.sh.done
+ case $(uname -s ) in
++ uname -s
/etc/postinstall/xlaunch.sh.done: line 2: uname: command not found
++ /usr/bin/cygpath -P
+ /usr/bin/mkdir -p
'/cygdrive/c/Users/jpbouchet/AppData/Roaming/Microsoft/Windows/Start
Menu/Programs/Cygwin-X'
+ /usr/bin/mkshortcut -P -i /usr/bin/xlaunch.exe -n Cygwin-X/XLaunch -a
'/usr/bin/bash.exe -l -c /usr/bin/xlaunch.exe' /usr/bin/run.exe
+ /usr/share/xlaunch/setupreg.sh add
/usr/share/Xlaunch/setupreg.sh: line 8: which: command not found
/usr/share/Xlaunch/setupreg.sh: line 8: cygpath: command not found
/usr/share/Xlaunch/setupreg.sh: line 9: which: command not found
/usr/share/Xlaunch/setupreg.sh: line 9: cygpath: command not found
/usr/share/Xlaunch/setupreg.sh: line 10: which: command not found
/usr/share/Xlaunch/setupreg.sh: line 10: cygpath: command not found
/usr/share/Xlaunch/setupreg.sh: line 14: which: command not found
/usr/share/Xlaunch/setupreg.sh: line 14: cygpath: command not found
/usr/share/Xlaunch/setupreg.sh: line 38: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 39: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 42: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 43: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 45: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 46: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 47: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 49: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 50: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 51: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 53: regtool: command not found
/usr/share/Xlaunch/setupreg.sh: line 54: regtool: command not found
# add a start menu shortcut
case $(uname -s) in *-WOW*) wow64=" (32-bit)" ;; esac
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X${wow64}"
/usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/xlaunch.exe -n
"Cygwin-X${wow64}/XLaunch" -a "/usr/bin/bash.exe -l -c /usr/bin/xlaunch.exe"
/usr/bin/run.exe
# add file association for opening and editing .xlaunch files
/usr/share/xlaunch/setupreg.sh add
--
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
Installer of Cygwin 64 seems to freeze when executing /etc/postinstall/xlaunch.sh - version 2.874
Hello, I try to install cygwin 64 on a windows 7 PC in order to let users open an X11 session via xlaunch on a linux server (gdm3). I have selected only 3 components of X11 to complete the default selection : xinit, xlaunch and Xorg server. The installer seems to freeze when it executes /etc/postinstall/xlaunch.sh. Information about the progression of the installation is blocked during several minutes with 99% Cygwin - Setup If I don't cancel the installation, it seems to finish correctly. 17:36:33 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/xlaunch.sh" 17:55:47 Changing gid to Administrators Ending cygwin install Is it a normal behaviour ? Best regards, Jean-Paul Bouchet Institut National de la Recherche Agronomique - Centre de Provence, Alpes, Côte d'Azur UR 1052 <http://w3.avignon.inra.fr/gafl/en> - Génétique et Amélioration des Fruits et Légumes Domaine Saint-Maurice - CS 60094 - F-84143 Montfavet cedex - France E-mail : <mailto:jean-paul.bouc...@avignon.inra.fr> Phone : +33-(0)4-3272-2723 - Fax : +33-(0)4-3272-2702 -- 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: bug#23314: gzip-1.7-1 regression: cannot redirect output of gzip -l
Come to think of it, that part of gzip can be simplified considerably, which
should make future problems like this less likely. I installed the attached
additional patch. Yay, 46 fewer files in the gzip tarball!
>From 02b67e301e66c8641230afbe8663f2d503c0f57b Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 19 Apr 2016 22:05:57 -0700
Subject: [PATCH] gzip: simplify by closing ourselves
This simplifies the previous fix, by avoiding the use of the
closein module. That module was problematic, as gzip normally
does not use stdio for output and never uses it for input.
Also, it is a heavyweight module, as it drags many files into lib
(c-ctype.c, c-ctype.h, closein.c, closein.h, closeout.c, closeout.h,
close-stream.c, close-stream.h, config.charset, c-strcasecmp.c,
c-strcaseeq.h, c-strcase.h, c-strncasecmp.c, fpending.c, fpending.h,
freadahead.c, freadahead.h, localcharset.c, localcharset.h, mbrtowc.c,
mbsinit.c, quotearg.c, quotearg.h, quote.h, ref-add.sin, ref-del.sin,
streq.h, wctype-h.c, wctype.in.h) and into m4 (closein.m4, closeout.m4,
close-stream.m4, codeset.m4, configmake.m4, fpending.m4, freadahead.m4,
glibc21.m4, localcharset.m4, locale-fr.m4, locale-ja.m4, locale-zh.m4,
mbrtowc.m4, mbsinit.m4, mbstate_t.m4, quotearg.m4, wctype_h.m4),
and these files are thus no longer needed.
* bootstrap.conf (gnulib_modules): Remove closein.
* gzip.c: Don't include closein.h.
(stdin_was_read): New static var.
(main): Don't use close_stdin.
Invoke finish_out to exit after outputting via stdio's stdout.
Close stdin after reading it.
Restore previous way of closing stdout.
(treat_stdin): Record that stdin was read.
(finish_out): New function.
---
bootstrap.conf | 1 -
gzip.c | 33 +
2 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/bootstrap.conf b/bootstrap.conf
index 25acaac..6cbaaa2 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -24,7 +24,6 @@ gnulib_modules='
announce-gen
calloc
close
-closein
dirname-lgpl
fclose
fcntl
diff --git a/gzip.c b/gzip.c
index 3b8de4d..4a51b13 100644
--- a/gzip.c
+++ b/gzip.c
@@ -63,7 +63,6 @@ static char const *const license_msg[] = {
#include
#include
-#include "closein.h"
#include "tailor.h"
#include "gzip.h"
#include "intprops.h"
@@ -206,6 +205,8 @@ static int volatile exiting_signal;
/* If nonnegative, close this file descriptor and unlink ofname on error. */
static int volatile remove_ofname_fd = -1;
+static bool stdin_was_read;
+
off_t bytes_in; /* number of input bytes */
off_t bytes_out;/* number of output bytes */
static off_t total_in; /* input bytes for all files */
@@ -317,6 +318,7 @@ local void install_signal_handlers (void);
local void remove_output_file (void);
local RETSIGTYPE abort_gzip_signal (int);
local void do_exit (int exitcode) ATTRIBUTE_NORETURN;
+static void finish_out (void);
int main (int argc, char **argv);
static int (*work) (int infile, int outfile) = zip; /* function to call */
@@ -427,8 +429,6 @@ int main (int argc, char **argv)
program_name = gzip_base_name (argv[0]);
proglen = strlen (program_name);
-atexit (close_stdin);
-
/* Suppress .exe for MSDOS, OS/2 and VMS: */
if (4 < proglen && strequ (program_name + proglen - 4, ".exe"))
program_name[proglen - 4] = '\0';
@@ -527,13 +527,13 @@ int main (int argc, char **argv)
case 'f':
force++; break;
case 'h': case 'H':
-help(); do_exit(OK); break;
+help (); finish_out (); break;
case 'k':
keep = 1; break;
case 'l':
list = decompress = to_stdout = 1; break;
case 'L':
-license(); do_exit(OK); break;
+license (); finish_out (); break;
case 'm': /* undocumented, may change later */
no_time = 1; break;
case 'M': /* undocumented, may change later */
@@ -580,7 +580,7 @@ int main (int argc, char **argv)
case 'v' + ENV_OPTION:
verbose++; quiet = 0; break;
case 'V':
-version(); do_exit(OK); break;
+version (); finish_out (); break;
case 'Z':
#ifdef LZW
do_lzw = 1; break;
@@ -664,6 +664,11 @@ int main (int argc, char **argv)
} else { /* Standard input */
treat_stdin();
}
+if (stdin_was_read && close (STDIN_FILENO) != 0)
+ {
+strcpy (ifname, "stdin");
+read_error ();
+ }
if (list)
{
/* Output any totals, and check for output errors. */
@@ -672,8 +677,11 @@ int main (int argc, char **argv)
if (fflush (stdout) != 0)
write_error ();
}
-if (to_stdout && synchronous &&
Re: bug#23314: gzip-1.7-1 regression: cannot redirect output of gzip -l
Thanks for reporting the problem. I installed the attached gzip patch on
savannah.
From 9167b7b9d5b68cea52bdd683b81a3b64381b7ff9 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 19 Apr 2016 17:43:09 -0700
Subject: [PATCH] gzip: fix bug with -l output to pipes
Problem reported by Christian Franke via Eric Blake in:
http://bugs.gnu.org/23314
* NEWS: Mention this.
* gzip.c (main): Do not close stdout twice when given -l.
Instead, -l now just fflushes stdout, so that fdatasync
can synchronize it if --synchronize is also specified.
* tests/list: New test case.
* tests/Makefile.am (TESTS): Add it.
---
NEWS | 3 +++
gzip.c| 18 ++
tests/Makefile.am | 1 +
tests/list| 31 +++
4 files changed, 45 insertions(+), 8 deletions(-)
create mode 100755 tests/list
diff --git a/NEWS b/NEWS
index fdae647..8f722e5 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,9 @@ GNU gzip NEWS-*- outline -*-
** Bug fixes
+ gzip -l no longer falsely reports a write error when writing to a pipe.
+ [bug introduced in gzip-1.7]
+
Port to Oracle Solaris Studio 12 on x86-64.
[bug present since at least gzip-1.2.4]
diff --git a/gzip.c b/gzip.c
index d66530a..3b8de4d 100644
--- a/gzip.c
+++ b/gzip.c
@@ -664,14 +664,16 @@ int main (int argc, char **argv)
} else { /* Standard input */
treat_stdin();
}
-if (list && !quiet && file_count > 1) {
-do_list(-1, -1); /* print totals */
-}
-if (to_stdout
-&& ((synchronous
- && (fdatasync (STDOUT_FILENO) != 0 && errno != EINVAL))
-|| close (STDOUT_FILENO) != 0)
-&& errno != EBADF)
+if (list)
+ {
+/* Output any totals, and check for output errors. */
+if (!quiet && 1 < file_count)
+ do_list (-1, -1);
+if (fflush (stdout) != 0)
+ write_error ();
+ }
+if (to_stdout && synchronous && fdatasync (STDOUT_FILENO) != 0
+&& errno != EINVAL && errno != EBADF)
write_error ();
do_exit(exit_code);
return exit_code; /* just to avoid lint warning */
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5022464..71cf4ad 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -20,6 +20,7 @@ TESTS = \
help-version\
hufts \
keep \
+ list \
memcpy-abuse\
mixed \
null-suffix-clobber \
diff --git a/tests/list b/tests/list
new file mode 100755
index 000..7576dc3
--- /dev/null
+++ b/tests/list
@@ -0,0 +1,31 @@
+#!/bin/sh
+# Exercise the --list option.
+
+# Copyright 2016 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+# limit so don't run it by default.
+
+. "${srcdir=.}/init.sh"; path_prepend_ ..
+
+echo zoology zucchini > in || framework_failure_
+cp in orig || framework_failure_
+
+gzip -l in && fail=1
+gzip -9 in || fail=1
+gzip -l in.gz >out1 || fail=1
+gzip -l in.gz | cat >out2 || fail=1
+compare out1 out2 || fail=1
+
+Exit $fail
--
2.5.5
--
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
Mintty font problem
Cygwin setup just updated some older packages while installing a requested new component and now mintty does not recognize fonts properly. I was previously using lucinda-console but now some default font is being used. When I try to change the mintty font through the Options... dialog, the following message appears when I press Select...: "There are no fonts installed. Open the Fonts folder from the Control Panel to install fonts." I've looked through the cygwin announce history and mintty v2.3.3 advertises some font support changes. I'm still running Windows XP on this machine and I'm wondering if it could be that this new version of mintty has not been tested on XP? -- 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
hi cygwin
Sup cygwin http://sixpackclub.net/spoken.php?action=h1f2rn98fwxnhbg2 cs...@yahoo.co.uk -- 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: Unwanted case-insensivity in file name globbing
Ken Brown cornell.edu> wrote: > ...don't forget about the registry setting you need in order to turn > on case sensitivity: > > http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames- casesensitive That's OK, I just need case-insensitive file globbing. I don't want to mess with the actual case sensitivity in Win 7 cuz who knows consequences (human or software) can result. Besides, I don't have permissions to change the registry, though I appreciate the awareness. -- 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: Unwanted case-insensivity in file name globbing
Jan Bruun Andersen jabba.dk> wrote: | Seems overly complicated for me. My current fstab looks like this: | | # /etc/fstab | # | #This file is read once by the first process in a Cygwin process tree. | #To pick up changes, restart all Cygwin processes. For a description | #see https://cygwin.com/cygwin-ug-net/using.html#mount-table | | # Device- Mount- FS-type Options Ignored | # name point | # - --- --- | --- | | C:/Users/home ntfsbinary,posix=1,user 0 0 | none/ cygdrivebinary,posix=0,user 0 0 | | If I remember correctly the cygdrive thing is what automatically maps | all my C:. D:, E:, etc drives to /C, /D, E and so on. | | The magic with posix is described here: | https://cygwin.com/cygwin-ug-net/using.html#mount-table | | posix=0 - Switch off case sensitivity for paths under this mount point | (default for the cygdrive prefix). | | posix=1 - Switch on case sensitivity for paths under this mount point | (default for all other mount points). Thanks, Jan. I was actually looking at that page, and totally glossed over the posix switch. Will try it (the machine is elsewhere). I realize that cygdrive maps all the letter drives, but I'm trying to cut down on the typed text. -- 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
Unwanted case-insensivity in file name globbing
I just replicated my Cygwin setup on Win 7 (64 bits) onto another Win 7 64- bit machine, including /etc/fstab c: /c ntfs binary,posix=0,user,auto d: /d ntfs binary,posix=0,user,auto e: /e ntfs binary,posix=0,user,auto f: /f ntfs binary,posix=0,user,auto g: /g ntfs binary,posix=0,user,auto i: /i ntfs binary,posix=0,user,auto o: /o ntfs binary,posix=0,user,auto r: /r ntfs binary,posix=0,user,auto s: /s ntfs binary,posix=0,user,auto So my home directory "~" is "C:\cygwin64\home\My.User.Name". I noticed that when I issue a command involving a file name pattern, it is not case sensitive in that directory. For example, "ls -d [A-Z]*" will return the folder "cat". Web searching revealed that it could be the bash shell option nocaseglob, but I confirmed that in my case, it is not set: $ shopt -p nocaseglob shopt -u nocaseglob I am also puzzled by the fact that when I cd to a subdirectory, the unwanted case insensivity is no longer present. I thought that I did something wierd in replicating my Cygwin setup, but when I tested my original setup on the 1st computer, I found the same selective case insensitivity. What other setting might cause this? How can I get bonafide Unix behaviour in the file name globbing? -- 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: workflow idiom to compare zip/tgz with folder subtree
Warren Young etr-usa.com> writes: Lots of good background for newbies to version control apps. Warren, thanks for the comprehensive map of version control apps for newbies. To be honest, I'm not sure when I will have a chance to get spun up on one. But I know where there is a good intro now. -- 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
New C compilation error using the Openwindow/xview-devel toolkit on current (September 2015) 32 bit Cygwin
I can no longer compile C code linked to the Openwindows/xview-devel toolkit using gcc in Cygwin 32 bits, installed on Windows 7 32 or 64 bit systems. I run setup-x86 weekly to update Cygwin - compilation ran fine in August 2015 but by mid September 2015 it was failing on the same code. I can reproduce this by compiling C code from the xview-examples package (from e.g., Debian i386 https://packages.debian.org/jessie/xview-examples ), to eliminate any issues with my specific code. For example, $ cd usr/share/doc/xviewg/examples/panels $ cc -O -I/usr/openwin/include simple_panel.c -L/usr/openwin/lib -lxview -lolgx -lX11 -o simple_panel In file included from /usr/openwin/include/xview/pkg.h:27:0, from /usr/openwin/include/xview/pkg_public.h:19, from /usr/openwin/include/xview/generic.h:39, from /usr/openwin/include/xview/xview_xvin.h:41, from /usr/openwin/include/xview/xview.h:18, from simple_panel.c:5: /usr/openwin/include/xview/notify.h:34:13: error: conflicting types for ‘ucontext_t’ typedef int ucontext_t; ^ In file included from /usr/include/sys/signal.h:357:0, from /usr/include/signal.h:5, from /usr/openwin/include/xview/xview_xvin.h:18, from /usr/openwin/include/xview/xview.h:18, from simple_panel.c:5: /usr/include/sys/ucontext.h:24:3: note: previous declaration of ‘ucontext_t’ was here } ucontext_t; ^ There now appears to be an issue with the definition of ucontext_t in xview-devel with respect to Cygwin. If I manually edit /usr/openwin/include/xview/base.h and change line 70 from undef to #define SYSV_UCONTEXT ... the example above then compiles fine. I cannot find any reference to recent Cygwin updates related to the definition of ucontext_t - and I may be fixing a symptom of something else rather than the underlying cause. Any suggestions? Thanks Paul cygcheck.out Description: Binary data -- 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: workflow idiom to compare zip/tgz with folder subtree
Andrey Repin yandex.ru> writes: > If anything, I would NOT recommend CVS to anyone making their first > steps into VCS world. Subversion is way more consistent, better > thought out and have about the same usability characteristics where > they are comparable. (And don't forget the marvelous svnbook.org > ...) The unly reason I was using CVS up until a month ago for some > of my projects is because I was lazy and did not convert them to > Subversion ten years ago. Ah, OK. Well thanks for the heads up. Time is so hard to come by these days that knowing about any non-starters is very helpful. Thank you. BTW, is your sig obsolete? What's this about 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: workflow idiom to compare zip/tgz with folder subtree
Eliot Moss wrote: > There are also various backup tools based on rsync and compression. > One of these is called duplicity, and it supports encryption as > well. But I suspect there are a number of these and that you can > find one that matches your task ... Andrey Repin wrote: > It seems he need comparison over reservation. I don't know of any > backup tools that offer differential view against backup content. > Not that I know many backup tools, though... Warren Young suggested: fossil Thank you all. I've perused and pondered. There is a key constraint that I neglected to mention. I am shuttling incremental work back and forth between two locations using disc. At one of the sites, the only possible tools are M$ Office and a snapshot of Cygwin. The full copy of the working hierarchy exists at the two sites (almost identical). The more restrictive site is the authoritative home of the historical snapshots, though I may have mini-snapshots at the alternative site. The comparison of the working file hierarchy with snapshots lets me vet what needs to be shuttle back and forth; the majority of the differences will not be relevant as the hierarcy exists at both sites. I use the same archival scheme for local snapshots and for shuttling work between sites, though the content is not the same (I won't take an entire local snapshot with me on disc most of the time). Most of the files are not software, though parallels can be drawn: Long SQL scripts, Matlab scripts, images, data files, VBA, Matlab files, text files, LaTeX files, image files, and M$ Office files (Access, Excel, Word, Powerpoint, PST). This is not a development environment, it is an analysis environment (with code hackery to that end). However, the evolution of files and version control requirements probably overlap (I can only guess as I've never worked in a regulated code development environment, relying instead on my own adhoc snapshots & incrementals). One differences from the days when I wrote "real" (compiled) code is that I'm not just archiving source code; some of the files are images, databases, etc., and take up a lot of space. I end up creating incrementals a lot more, or simply leaving the big files out of the snapshot routine (relying on very old snapshots). My analysis strategy is strongly influenced by this; I try to avoid computational approaches that rely on intermediately generated data that need to be archvied. As much as possible, everything should be quickly generatable from raw client input data files. Been able to get away with that so far, with a great deal of effort. I rely alot on bash hackery, even though I'm no graybeard. "find", "diff -qr", and "xargs" are indispensible, and using vim window splitting, it is very efficient to browse the diff output and warp to discrepant text files, and even delve into zip files to open its content, and then use vimdiff to cruise the discrepancies. The synergy between vim & bash are (to me) like magic, scripting up copies and such and piping them to bash. For the most part, however, you need to unpack the snapshot (or rebuild it from incrementals). Andrey is right, the main thing causing me to put the question out there is the desire to avoid this. I noticed that fossil & cvs are part of cygwin. I will have to bite the bullet & try a few baby steps at some point. -- 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: workflow idiom to compare zip/tgz with folder subtree
Andrey Repin yandex.ru> writes: > Git, Subversion... basically any sane VCS out there. Ah, yesI've managed to avoid version control all these years because I wanted the convenience of bash file management and changing things on a whim as I see fit. And for lack of time to learn yet another system. I see the lesson here. The right tool for the right job, and there's no getting around the learning curve and the sacrifice in flexibility. OK. I have it on my radar. I will have to find time to try it out. Thank you! -- 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
workflow idiom to compare zip/tgz with folder subtree
I currently take snapshots of selected portions of a folder subtree using zip files. Sometimes, I use command-line zip, but other times I'll use the Windows Compressed Zip folder. I find myself frequently unzipping the snapshots into temp folders just so that I can use the unix diff utility (via cygwin) to see what the differences are with the live folder tree. Is there a way to take regular snapshots that I can compare with the live folder subtree without having to unpack it? I'm not married to zip. However, tar doesn't quite do it. My vague recollection is that it will check that the files in a tgz snapshot matches what is in the live folder subtree, but it won't report what is in the live folder subtree which isn't in the tgz snapshot. I've also posted this to: http://answers.microsoft.com/en-us/windows/forum/windows_7-files/workflow-idiom-to-compare-ziptgz-with-folder/631c39ae-609d-402f-88ba-2681a836f11e?tm=1442922342392 -- 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: readline behaves differently in R than in bash
Marco Atzeri gmail.com> writes: >On 4/17/2015 10:28 PM, paul wrote: >> I "set editing-mode vi" in ~/.inputrc. In bash, it responds as >> expected to (say) "dt,", which deletes characters upto the next >> comma. It does not do this in R; instead, that series of >> keystrokes simply causes the next two keystrokes to be consumed >> without any effect. I guess it would be wrong to assume that R >> uses the same readline implementation as bash? Is there anything I >> can set to get the expected behaviour? >> >> 64-bit Cygwin DLL version 1.7.28 >> R version 3.0.1-1 > > it works fine for me. > > $ uname -svr > CYGWIN_NT-6.1-WOW 1.7.35(0.287/5/3) 2015-03-04 12:07 > > $ R --version > R version 3.1.3 (2015-03-09) -- "Smooth Sidewalk" My versions are: $uname -svr CYGWIN_NT-6.1 1.7.28(0.271/5/3) 2014-02-09 21:06 $R --version R version 3.0.1 (2013-05-16) -- "Good Sport" Copyright (C) 2013 The R Foundation for Statistical Computing Platform: x86_64-unknown-cygwin (64-bit) The problem is likely due to my old version, then, or perhaps due to the 64-bit width. Unfortunately, in my work place, we are not able to update things at will. I'll try to work the ropes a bit more on that front. Thanks, 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
readline behaves differently in R than in bash
I "set editing-mode vi" in ~/.inputrc. In bash, it responds as expected to (say) "dt,", which deletes characters upto the next comma. It does not do this in R; instead, that series of keystrokes simply causes the next two keystrokes to be consumed without any effect. I guess it would be wrong to assume that R uses the same readline implementation as bash? Is there anything I can set to get the expected behaviour? 64-bit Cygwin DLL version 1.7.28 R version 3.0.1-1 -- 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: "R" help leaves out lines of text
Marco Atzeri gmail.com> writes: >> I am ramping up on the R statistical analysis environment. I find >> that the help leaves out entire lines of text. The pager is >> /usr/lib/R/bin/pager. I changed it to /bin/less, but I see the >> same symptom. The problem shows up both in xterm and mintty. The >> computer is in a locked down environment, so a straight update of >> cygwin packages is not an option. From the R forum, the problem >> might be due to improper handling of line endings by the R port to >> cygwin. >> >> Is there anything further I can try to circumvent the problem? >> >> My version info is: >> >> 64-bit Cygwin DLL version 1.7.28 >> R version 3.0.1-1 >> > > Are the input files Unix style or DOS style ? > Can you give an example to replicate your finding ? > > I can that test than if the last R-3.1.3-1 package behaves correctly > or not. R-3.0.1-1 package is almost 2 years old. I can't actually find the help files; I suspect that they are not just plain text. I tried looking for html versions of the help pages by ferruting through the R.home() subtree. Haven't found them so far. There are package pages in subdirectories /html/00Index.html, but they just contain links to html files that don't reside in my R.home() subtree. There are also subdirectories /help, but they contain pages that I don't recognize (*.rds, *.rdb, *.rdx). As an example, I've attached the output from ?help at the very end below. My current workaround is to use the following in my ~/.Rprofile, which forces the help to a browser: options(browser="cygstart") options(help_type="html") Here's the bad result from help(help,help_type="text"): help package:utils R DocumentationDocumentation Description: Usage: help(topic, package = NULL, lib.loc = NULL, verbose = getOption("verbose"), try.all.packages = getOption("help.try.all.packages"), help_type = getOption("help_type")) Arguments: lines 1-23- ("less" prompt) Details: The following types of help are available: Plain text help If a package is specified, (text or, in interactive use only, HTML) information on the package, including hints/links to suitable help topics. lines 24-46- ("less" prompt) Offline help: Note: References: Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988) _The New S Language_. Wadsworth & Brooks/Cole. See Also: Examples: help() help(help) # the same lines 47-69- ("less" prompt) help(lapply) help("for") # or ?"for", but quotes/backticks are needed try({# requires working TeX installation: help(dgamma, help_type = "pdf") ## -> nicely formatted pdf -- including math formula -- for help (dgamma): system2(getOption("pdfviewer"), "dgamma.pdf", wait = FALSE) }) help(package = "splines") # get help even when package is not loaded topi <- "women" help(topi) try(help("bs", try.all.packages = FALSE)) # reports not found (an error) help("bs", try.all.packages = TRUE) # reports can be found # in package 'splines' ## For programmatic use: topic <- "family"; pkg_ref <- "stats" help((topic), (pkg_ref)) lines 70-92- ("less" prompt) help("for") # or ?"for", but quotes/backticks are needed try({# requires working TeX installation: help(dgamma, help_type = "pdf") ## -> nicely formatted pdf -- including math formula -- for help (dgamma): system2(getOption("pdfviewer"), "dgamma.pdf", wait = FALSE) }) help(package = "splines") # get help even when package is not loaded topi <- "women" help(topi) try(help("bs", try.all.packages = FALSE)) # reports not found (an error) help("bs", try.all.packages = TRUE) # reports can be found
"R" help leaves out lines of text
I am ramping up on the R statistical analysis environment. I find that the help leaves out entire lines of text. The pager is /usr/lib/R/bin/pager. I changed it to /bin/less, but I see the same symptom. The problem shows up both in xterm and mintty. The computer is in a locked down environment, so a straight update of cygwin packages is not an option. From the R forum, the problem might be due to improper handling of line endings by the R port to cygwin. Is there anything further I can try to circumvent the problem? My version info is: 64-bit Cygwin DLL version 1.7.28 R version 3.0.1-1 -- 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
mingw-w32api needs to be upgraded to 4.0.1
I maintain an app called x3270, along with its Windows variant, wc3270. One of the build environments for wc3270 used to be Cygwin, but for well over a year, it has been impossible to build it because of a bug in MinGW 4.0, which was fixed in MinGW 4.0.1 in September 2013. (The current version of Cygwin mingw-runtime and mingw-w32api is "4.0-1", which I take to be a minor variant of 4.0, because it still contains the bug.) The bug is that if a file is linked against the 'winspool' library, the resulting Windows executable points at a nonexistent DLL called 'winspool.dll', instead of or 'winspool.drv'. The bug and the fix are described in detail in this thread: http://mingw.5.n7.nabble.com/quot-winspool-dll-was-not-found-quot-error-on-startup-after-upgrading-to-gcc-4-8-1-td32324.html I had expected that Cygwin's MinGW would be upgraded shortly after 4.0.1 appeared, but this does not appear to have been the case. -- /pdm/ Cygwin Configuration Diagnostics Current System Time: Fri Jan 09 03:46:31 2015 Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 Path: C:\cygwin64\usr\local\bin C:\cygwin64\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\Common Files\Adobe\AGL C:\Program Files (x86)\QuickTime\QTSystem Output from C:\cygwin64\bin\id.exe UID: 1001(pdm) GID: 513(None) 513(None) 545(Users) 1000(HomeUsers) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'pdm' PWD = '/home/pdm/wc3270-3.3' HOME = '/home/pdm' HOMEPATH = '\Users\pdm' APPDATA = 'C:\Users\pdm\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'splunge' SHELL = '/bin/bash' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 37 Stepping 2, GenuineIntel' PROFILEREAD = 'true' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/home/pdm' ORIGINAL_PATH = '/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files (x86)/Common Files/Adobe/AGL:/cygdrive/c/Program Files (x86)/QuickTime/QTSystem' USERDOMAIN = 'splunge' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'pdm' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'en_US.UTF-8' USERPROFILE = 'C:\Users\pdm' TZ = 'America/Chicago' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\SPLUNGE' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'AMD64' LOCALAPPDATA = 'C:\Users\pdm\AppData\Local' ProgramData = 'C:\ProgramData' EXECIGNORE = '*.dll' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' OPENSSL_CONF = 'C:\OpenSSL-Win32\bin\openssl.cfg' HOMEDRIVE = 'C:' VBOX_MSI_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\' COMSPEC = 'C:\Windows\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\Windows' PRINTER = 'Canon MX860' PROCESSOR_REVISION = '2502' VS100COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '4' asl.log = 'Destination=file' SESSIONNAME = 'Console' COMPUTERNAME = 'SPLUNGE' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Console\Cygwin (default) = 0x ColorTable01 = 0x0080 ColorTable02 = 0x8000 ColorTable03 = 0x00808000 ColorTable04 = 0x0080 ColorTable05 = 0x00800080 ColorTable06 = 0x8080 ColorTable07 = 0x00c0c0c0 ColorTable08 = 0x00808080 ColorTable09 = 0x00ff ColorTable10 = 0xff00 ColorTable11 = 0x0000 ColorTable12 = 0x00ff ColorTable13 = 0x00ff00ff ColorTable14 = 0x ColorTable15 = 0x00ff CursorSize = 0x0064 FaceName = 'Lucida Console' FontFamily = 0x0036 FontSize = 0x000e FontWeight = 0x0190 HistoryBufferSize = 0x0032 HistoryNoDup = 0x InsertMode = 0x0001 NumberOfHistoryBuffers = 0x0004 PopupColors = 0x00f5 QuickEdit = 0x ScreenBufferSize = 0x012c0050 ScreenColors = 0x0007 WindowSize = 0x00320050 HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Installations (default) = '\??\C:\cygwin64' 1456d1caae951ae4 = '\??\C:\cygwin-x86' HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin64' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin64' HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin HKEY_LOCAL_M
Re: Force "ls" to show .exe extension
Andrey Repin yandex.ru> writes: >> I don't like using the back ticks myself because of its atrocious >> readability, but I'm not religious about it. > > Then don't use them. Use "$( )" instead. Aside readability issues, > it also solve nesting and quoting problems. So much better...thanks, Andrey! -- 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: Force "ls" to show .exe extension
Bob McGowan symantec.com> writes: | Back to Paul's problem, getting a list of the actual filenames, as | they actually exist in the filesystem, can be handled by 'find', I | think. At least it worked in my simple test setup, above. | | $ find . -name abc | ./abc | $ find . -name 'abc*' | ./abc | ./abc.bat | ./abc.exe | ./abc.sh | | Since find prints each file name on a line by itself, filenames with | spaces just "work": | | $ touch 'pdq xyz' | $ find . | . | ./abc | ./abc.bat | ./abc.exe | ./abc.sh | ./pdq xyz | | To process the above output, use a 'while' loop with the 'read' | command and quote the shell variable in the loop body to preserve | the single filename with spaces: | | $ find . | | > while read filenames | > do | > file "$filenames" | > done | .: directory | ./abc: empty | ./abc.bat: empty | ./abc.exe: empty | ./abc.sh: empty | ./pdq xyz: empty | | The above is for illustration only. It is not efficient, since | 'file' is run 6 times, when it could have run once with multiple | file names, but then the quoting wouild be more difficult. You | would replace it with 'ls -l' to get individual file metadata, | though again it would be inefficient. | | Using 'xargs' would improve this, assuming the right parameters are | used. This will work with 'xargs' and 'cpio', I'm not sure which | other commands might support literal NULL termination of strings | (note the 0 (zero) in each command's args). | | find . -print0 | xargs -0 file | .: directory | ./abc: empty | ./abc.bat: empty | ./abc.exe: empty | ./abc.sh: empty | ./pdq xyz: empty It certainly is educational. For the original problem, though, I'd like to keep it simple enough to fit into one line. It has to accept output from "type" and must allow for "ls -l" and/or "ls -ltd" (or the like): $ls -d `type -pa pdfcrop | sed -e 's/.*/&*/'` /bin/pdfcrop@ /home/User.Name/bin/pdfcrop.exe* /usr/bin/pdfcrop@ $ls -ld `type -pa pdfcrop | sed -e 's/.*/&*/'` lrwxrwxrwx 1 User.Name Domain Users 48 Nov 10 16:35 /bin/pdfcrop -> /usr/share/texmf-dist/scripts/pdfcrop/pdfcrop.pl* -rwx--+ 1 User.Name Domain Users 33792 Jun 21 2013 /home/User.Name/bin/pdfcrop.exe* lrwxrwxrwx 1 User.Name Domain Users 48 Nov 10 16:35 /usr/bin/pdfcrop -> /usr/share/texmf-dist/scripts/pdfcrop/pdfcrop.pl* I don't like using the back ticks myself because of its atrocious readability, but I'm not religious about it. P.S. Gotta luv the gmane captcha words. -- 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: Force "ls" to show .exe extension
Buchbinder, Barry (NIH/NIAID) [E] niaid.nih.gov> writes: >Paul sent the following at Tuesday, January 06, 2015 7:12 PM >> I'm wading through many files in two file trees. In particular, I'm >> looking at corresponding directories in the two trees where "diff >> -qr" revealed differences. I want the absolute truth of what the >> filename is with minimal distractions about how to achieve that. >> Then, I can focus on figuring how those files came about, and how >> the differences arose. > > Not a Cygwin solution but the following should give real names. > > cmd /c dir /b /a: > > (The /a: makes sure that hidden files are listed.) That works great, Barry. The following also works: cmd /c dir /b /a: | dos2unix | xargs ls -ltd However, variation#1 type -pa pdfcrop | xargs cmd /c dir /b /a: doesn't work because dir expects DOS filenames (I suspect). Variation#2 type -pa pdfcrop | xargs cygpath -aw | xargs cmd /c dir /b /a: doesn't work because the backward slashes are interpretted by Escapes by bash. Variation#3 (on *one* line): type -pa pdfcrop | xargs cygpath -aw -t mixed | xargs cmd /c dir /b /a: doesn't work because Parameter format not correct - "cygwin64" To find out what was going on, I stuck an "echo" in front of cmd, which yielded the following (on *one* line): cmd /c dir /b /a: C:/cygwin64/home/User.Name/bin/pdfcrop C:/cygwin64/usr/share/texmf-dist/scripts/pdfcrop/pdfcrop.pl C:/cygwin64/usr/share/texmf-dist/scripts/pdfcrop/pdfcrop.pl I think the dir command is interpreting /cygwin64 as a command switch. -- 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: Force "ls" to show .exe extension
Andrey Repin yandex.ru> writes: >> I'm wading through many files in two file trees. In particular, >> I'm looking at corresponding directories in the two trees where >> "diff -qr" revealed differences. I want the absolute truth of what >> the filename is with minimal distrations about how to achieve that. >> Then, I can focus on figuring how those files came about, and how >> the differences arose. > > Use more appropriate tools. I.e. Far manager have standard > file/directory comparison plugin. Which can quickly compare paths > and or contents of the files. However, it will not show differences > inside files, only show that they are different, but you can always > augment it with view: "\$Revision.*\$" -I "\$Date.*\$" -I "\$Author.*\$" -I "\$URL.*\$" > !?$UnixDiff$Options ((-c, -b etc.)):?! --strip-trailing-cr -- > "!#!\!.!" "!^!\!.!" > > P.S. I'm not saying that this can not be achieved with Cygwin > tools, but even then, using "ls" to compare files one by one is > hardly efficient. Andrey, I appreciate the awareness that you gave of Far Manager, but I'm going to have to say that in this case, it's not the most suitable course of action. We're a locked down shop, so installing new tools is problematic. Even if it was available, however, the prevailing environment is that committing time to explore new tools is carefully weighed against what else is not being done. I realize that the latter doesn't fly very well in an open forum in which people freely donate their time to help, but it is a reality that can't be changed for many. Finally, if Far Manager were installable, whether to give it a try would be weighed against the fact that a lot more ls is being used in figuring how differences between file trees. It's actually a small part, and I was just giving a bit of context around it. Nevertheless, as I said, I appreciate the extra awareness of that tool. -- 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: Force
Eric Blake redhat.com> writes: > alias xargs='xargs ' > alias ls='ls --append-exe' > find -pa pdfcrop | xargs ls > > will execute 'ls --append-exe', but > > alias xargs='xargs ' > alias ls='ls --append-exe' > find -pa pdfcrop -print0 | xargs -0 ls > > will not, unless you also: > > alias -- -0='-0 ' The bash man page says " A trailing space in value causes the next word to be checked for alias substitution when the alias is expanded." Got it. Thanks. -- 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: Force "ls" to show .exe extension
Andrey Repin yandex.ru> writes: >> ...if I have ~/bin/pdfcrop.exe, the command "ls ~/bin/pdfcrop" >> shows pdfcrop rather than pdfcrop.exe. Is there any way to force >> ls to show the full filename (including extension) if it matched >> the ls argument, even if the ls argument doesn't specify the >> extension? I read >> http://cygwin.com/cygwin-ug-net/using-specialnames.html, which >> helps explain the situation, but not a solution. > > I see people are diving deep to find a "solution", but noone has > asked, what is the problem they are trying to solve here. So, let > me ask it: what is the problem? Hello, Andrey, I'm wading through many files in two file trees. In particular, I'm looking at corresponding directories in the two trees where "diff -qr" revealed differences. I want the absolute truth of what the filename is with minimal distrations about how to achieve that. Then, I can focus on figuring how those files came about, and how the differences arose. -- 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: Force
Eric Blake redhat.com> writes: |On 01/06/2015 02:28 PM, Paul wrote: |>Paul gmail.com> writes: |>> Both solutions are great. I'll set the --append-exe in my bash |>> aliases, and for systems outside of my normal working environment |>> (e.g., working with someone on their unix sessions), I know I can |>> force display of .exe using asterisk. |> |> Drat. If I pipe files to 'xargs ls', the unaliased ls command is |> used: |> |>type -pa pdfcrop | xargs ls | | alias xargs='xargs ' | | Then the alias expansion of xargs will in turn allow alias expansion | of the next argument. (Except that you then have to also create | trailing-space aliases for all options you commonly pass to xargs | between 'xargs' and the final command name). I'm not sure what you mean by needing trailing space aliases for common xargs options, but I'm going to take that as a warning of dragons lurking in that direction and avoid it. | Sadly, xargs is one of the cases where shell functions won't help | (xargs doesn't execute the shell function). Your other solution is | to modify $PATH to point to a directory under your control as the | first thing, where 'cat /your/ls' contains: | | #!/bin/sh | exec /bin/ls --append-exe "$ " | | such that your script then gets picked up by xargs, and you no | longer have to worry about aliases. OK, I'll keep that one in mind -- wrapper scripts rather than aliases and functions. Thanks. -- 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: Force "ls" to show .exe extension
Paul gmail.com> writes: > Both solutions are great. I'll set the --append-exe in my bash > aliases, and for systems outside of my normal working environment > (e.g., working with someone on their unix sessions), I know I can > force display of .exe using asterisk. Drat. If I pipe files to 'xargs ls', the unaliased ls command is used: type -pa pdfcrop | xargs ls I can always append asterisks to each pdfcrop path using sed, or even explicitly type --append-exe [:(] . -- 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: Force "ls" to show .exe extension
Tom Robinson gmail.com> writes: >If you don't want to specify the extension, can you specify as >asterisk? > >[3236 CBGSAS04:~/Documents]$ touch name.exe > >[3237 CBGSAS04:~/Documents]$ ls -l name >-rw-r--r--+ 1 cbg.tom Domain Users 0 Jan 7 09:34 name > >[3238 CBGSAS04:~/Documents]$ ls -l name.exe >-rw-r--r--+ 1 cbg.tom Domain Users 0 Jan 7 09:34 name.exe > >[3239 CBGSAS04:~/Documents]$ ls -l name* >-rw-r--r--+ 1 cbg.tom Domain Users 0 Jan 7 09:34 name.exe Yaakov Selkowitz cygwin.com> writes: > ls --append-exe ~/bin/pdfcrop Tom, Yaakov, Both solutions are great. I'll set the --append-exe in my bash aliases, and for systems outside of my normal working environment (e.g., working with someone on their unix sessions), I know I can force display of .exe using asterisk. Thanks! -- 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
Force "ls" to show .exe extension
Right now, if I have ~/bin/pdfcrop.exe, the command "ls ~/bin/pdfcrop" shows pdfcrop rather than pdfcrop.exe. Is there any way to force ls to show the full filename (including extension) if it matched the ls argument, even if the ls argument doesn't specify the extension? I read http://cygwin.com/cygwin-ug-net/using-specialnames.html, which helps explain the situation, but not a solution. -- 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
filename completion fails for quoted command
According to the discussion at http://thread.gmane.org/gmane.os.cygwin/148438, file name completion depends on the preceding command if bash-completion is installed. Since I didn't want this behaviour, I uninstalled bash-completion. However, I just noticed that completion doesn't work when trying to type the command: 'rm' ~/tmp/tmp.tar But it works the command is not adorned with single quotes. Is there anything I can do to make completion independent of the command and how it is typed? -- 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: cygwin Digest 7 Dec 2014 10:57:56 -0000 Issue 8995
Based on the output of the identify-compilers.sh script below, it appears that the following C compilers are available on Cygwin. Those labeled "Cygwin" require the cygwin1.dll file to be available. What is the difference between the "pc" and "w64" compilers? Why is there no x86_64-pc-mingw-gcc.exe executabe? Are there any other C compilers available? /usr/bin/gcc.exe64-bit Cygwin /usr/bin/i686-pc-cygwin-gcc.exe 32-bit Cygwin /usr/bin/i686-pc-mingw32-gcc.exe32-bit /usr/bin/i686-w64-mingw32-gcc.exe 32-bit /usr/bin/x86_64-pc-cygwin-gcc.exe 64-bit Cygwin /usr/bin/x86_64-w64-mingw32-gcc.exe 64-bit $ cat identify-compilers.sh #!/bin/bash for c in $(ls -1 /usr/bin/*gcc.exe); do echo === compiler: $c $c -o hello.exe hello.c objdump -p hello.exe | grep -i "cygwin" objdump -p hello.exe | grep -i "64$" rm hello.exe done On Sun, Dec 7, 2014 at 4:30 PM, wrote: > Based on the output of the identify-compilers.sh script below, it appears > that the following C compilers are available on Cygwin. Those labeled > "Cygwin" require the cygwin1.dll file to be available. > > What is the difference between the "pc" and "w64" compilers? > > Why is there no x86_64-pc-mingw-gcc.exe executabe? > > Are there any other C compilers available? > > /usr/bin/gcc.exe64-bit Cygwin > /usr/bin/i686-pc-cygwin-gcc.exe 32-bit Cygwin > /usr/bin/i686-pc-mingw32-gcc.exe32-bit > /usr/bin/i686-w64-mingw32-gcc.exe 32-bit > /usr/bin/x86_64-pc-cygwin-gcc.exe 64-bit Cygwin > /usr/bin/x86_64-w64-mingw32-gcc.exe 64-bit > > $ cat identify-compilers.sh > #!/bin/bash > for c in $(ls -1 /usr/bin/*gcc.exe); do > echo === compiler: $c > $c -o hello.exe hello.c > objdump -p hello.exe | grep -i "cygwin" > objdump -p hello.exe | grep -i "64$" > rm hello.exe > done -- 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: pdfnup ignores ~/.pdfjam.conf
Paul gmail.com> writes: |Ken Brown cornell.edu> writes: |> |> I've never used pdfnup, but it's a shell script whose last line is |> |>exec pdfjam --suffix nup --nup 2x1 --landscape "$ " |> |> So it's explicitly supplying options that will override the settings |> in ~/.pdfjam.conf. This is consistent with the documentation for |> pdfnup. The latter doesn't mention ~/.pdfjam.conf; it says to |> supply command line options to override the defaults. | | Shucks. Thanks for sleuthing that out. Looks like I'll have to | create my own variation of the script. Or just create an alias for | pdfnup. Or just directly invoke pdfjam (what was I thinking). -- 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: pdfnup ignores ~/.pdfjam.conf
Ken Brown cornell.edu> writes: |On 12/3/2014 6:01 PM, Paul wrote: |> I'm using pdfjam that comes with 64-bit cygwin's |> texlive-collection-binextra package, dated 29 May 2013. I have the |> following in my ~/.pdfjam.conf: |> |> paper='letterpaper' |> nup='1x2' |> landscape='landscape' |> frame='true' |> |> I invoke pdfjam using |> |> pdfnup filename.pdf |> |> and the messages show that the ~/.pdfjam.conf is being read, as are |> the switches therein. <...snip...> |> The "Effective call" above shows that ~/.pdfjam.conf is being |> ignored, even though the switch settings are being read. The |> output confirms this. However, if I specify the switch settings in |> the pdfnup statement itself, they are accepted. | | I've never used pdfnup, but it's a shell script whose last line is | |exec pdfjam --suffix nup --nup 2x1 --landscape "$ " | | So it's explicitly supplying options that will override the settings | in ~/.pdfjam.conf. This is consistent with the documentation for | pdfnup. The latter doesn't mention ~/.pdfjam.conf; it says to | supply command line options to override the defaults. Shucks. Thanks for sleuthing that out. Looks like I'll have to create my own variation of the script. Or just create an alias for pdfnup. -- 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
pdfnup ignores ~/.pdfjam.conf
I'm using pdfjam that comes with 64-bit cygwin's texlive-collection-binextra package, dated 29 May 2013. I have the following in my ~/.pdfjam.conf: paper='letterpaper' nup='1x2' landscape='landscape' frame='true' I invoke pdfjam using pdfnup filename.pdf and the messages show that the ~/.pdfjam.conf is being read, as are the switches therein. pdfjam: This is pdfjam version 2.08. pdfjam: Reading any site-wide or user-specific defaults... ## ## From /home/User.Name/.pdfjam.conf: ## paper='letterpaper' nup='1x2' landscape='landscape' frame='true' pdfjam: Effective call for this run of pdfjam: /bin/pdfjam --suffix nup --nup '2x1' --landscape -- filename.pdf - pdfjam: Calling pdflatex... pdfjam: Finished. Output was to '/home/User.Name/tmp/filename-nup.pdf'. The "Effective call" above shows that ~/.pdfjam.conf is being ignored, even though the switch settings are being read. The output confirms this. However, if I specify the switch settings in the pdfnup statement itself, they are accepted. What am I doing wrong in setting up ~/.pdfjam.conf? If all is correct, does anyone else see this problem? P.S. In a corporate environment, updating packages is problematic. -- 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: Direct/efficient way to chop off trailing \n
Andrey Repin yandex.ru> writes: > I like bash, but it's no damned explorer, and can't be the one. > Simple for lack of visualization. My regular "shell" is > http://farmanager.com/ I would have said that bash is not a damned explorer -- rather, it's a darn good shell, which can often times be much better than an explorer. pushd +3. vim'ing on the command line. fc. NewCommand !!:$ diff -qr Long/Path/1 Another/Long/Path/From/Dir 2>&1 | tee ~/tmp/diff.out tar cf - Some/Directory | ( cd Other/Long/Path ; tar xf - ) find ... | xargs , etc., etc. How can *any* non-command-line compete. It would be like having one's hands chopped off. As for Far Manger, unfortunately, my environment is locked down. It took a very long time to get cygwin, and an old snapshot at that. >> and I am *never* able to work exclusively in cygwin. > >> I suppose you can always use cygstart to launch app files >> or executables, but Windows can be very inconsistent at times. >> I never know when cygstart will launch a new instance of an >> already-running app. > > That's not even Windows - that's a per-application behavior. Yes, but even in the Office suite, I've been surprised in the past. It is not trustable. -- 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: Direct/efficient way to chop off trailing \n
Keith Christian wrote:
> This function echoes the present directory to the clipboard, so that
> I don't have to enter the path manually.
>
> I use this function in a script that sources when a bash shell is
> started. Also echoes the path to the terminal for verification.
> Handy for pasting directly into windows file dialogs.
>
> function xx() {
> DESCRIPTION="Copy the Windows drive/path/filename to the
clipboard"
> cygpath -w "`pwd`"|tr -d "\012"|sed -e
> 's/$/\\/'|putclip;echo;getclip;echo
> }
Thanks, Keith. I think it will be educational for me just to figure
this out.
Andrey Repin wrote:
> Most people either use Cygwin tools in isolation, or use Cygwin
> tools from Windows tools. The opposite is rare, and mostly boils
> down to scripting, where you naturally use $(cygpath ...) to produce
> desired results.
Which I find odd. If you like bash, then that's going to be your
explorer, and I am *never* able to work exclusively in cygwin.
I suppose you can always use cygstart to launch app files
or executables, but Windows can be very inconsistent at times. I
never know when cygstart will launch a new instance of an
already-running app. Also, I often encounter the need to specify a
file location but not emulate a double-click on that file.
>> So I can see why such a [\n chopping] switch has never been
>> developed. It's probably only needed for cygwin users, as it is
>> the *unixy crowd that uses both Windows & *nix at the same time.
>
> The cygpath tool is Cygwin specific :) So there's no contradiction
> to your words.
Yeah, I suppose that was a circular truth. I should have said that
outside of cygwin, few people need to operate in both the POSIX and
Windows world at the same time. I guess those cases would be the ones
in which cygpath is used, and those are also the cases in which it
would be handy to have \n chopping capability built in to cygpath.
Eliot Moss wrote:
> You could write my solution as:
>
> echo -n `cygpath -aw foo`>/dev/clipboard
>
> though the ` (backtick) notation is deprecated these
> days and $(...) is described as preferred. But for many
> little things like these I write bash functions (or
> aliases, when they work, which they don't here).
Yeah, it's from decades ago, when I started dabbling in unix.
> The echo solution has the good property that echo is
> a shell built-in and so does not require spawning
> another process. You had complained about speed, so
> even though the echo approach does not seem to top
> you list for elegance, it might for performance
Eric Blake wrote:
> The same is true of printf.
I don't care about the computational speed, I probably won't notice
any difference. I care about reducing it to the simplest sequence of
actions for the user, not only in terms of keystrokes, but also the
cognitive simplicity of the code (which is pretty subjective, I know).
I will give you code idiom a try. Thanks.
Eric Blake wrote:
> 'echo -n' is not portable (in fact, you can disable it in bash, and
> it may misbehave if cygpath outputs a leading - or contains any \);
> it's better to use 'printf' for that purpose:
>
> printf %s `cygpath -aw foo`>/dev/clipboard
A new bash command of which I was not aware. Thanks!
Buchbinder, Barry wrote:
> Converting \n line endings to \r\n might work for you when you paste
> into a Windows app. It does for me.
>
> cygpath -aw foo/bar | putclip -d
This is awesome! Even better than
cygpath -aw foo/bar | unix2dos > /dev/clipboard
Thanks a million!!!
--
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: Direct/efficient way to chop off trailing \n
On 2014-10-01, Paul.Domaskis wrote:
> cygpath -aw foo | tr -d '\n' > /dev/clipboard
Gary Johnson wrote:
> Define a function in your ~/.bashrc.
>
> winclip()
> {
> cygpath -aw "$ " | tr -d '\n' > /dev/clipboard
> }
>
> Then just execute
>
> winclip TheFile
Jim Garrison wrote:
> Sounds like cygpath needs a "-n" option which eliminates the
> trailing newline.
Eliot Moss wrote:
> echo -n $(cygpath -aw foo) > /dev/clipboard?
Gary, I was hoping for a magic bullet code idiom so that I don't have
to haul around a growing .alias.bash file. But I think your solution
might be the only one that significantly cuts down on the typing.
Jim, I think you're right. cygpath could benefit a lot from a -n
switch to suppress the new line. From google, however, it's actually
just li'l olde me that would benefit as no one else seems to have the
want for it. So I can see why such a switch has never been developed.
It's probably only needed for cygwin users, as it is the *unixy crowd
that uses both Windows & *nix at the same time.
Eliot, your solution takes 2 characters less than mine. If I want to
live without spaces aroud the "$(" and the ")". Which I suppose I
could do, for 2 characters. I'm a bit enamoured of the linear
simplicity of my original pipeline, though. Appreciate the other
perspective, though.
Thank you all.
--
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
Direct/efficient way to chop off trailing \n
Running bash in a Windows environment, I often find the need to generate a full Windows path to a file so that I can access the file from a Windows app. If I use cygpath -aw TheFile > /dev/clipboard I can paste into the Windows file-opener without browsing. Also, I don't need to mouse around to highlight the result of cygpath. However, the clipboard always contains an invisible carriage return, which I have to remove by pressing backspacing. This doesn't visibly change anything, but it does remove the trailing \n which chokes up Windows. Since I hate manually deleting stuff that I can't see, the most efficient way around this seems to be: cygpath -aw | tr -d '\n' > /dev/clipboard This is starting to get longer and longer. It is comprising the whole goal of getting a sequence of operations that is so brief that one does not sigh at having to do it countless times. Is there a more succinct way to get a clean path for a file from the bash shell into the Windows clipboard? -- 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: No file name completion for file names start with underscore
Eliot Moss cs.umass.edu> writes: >On 9/24/2014 6:19 PM, Paul.Domaskis wrote: >>Andrey Repin yandex.ru> writes: >>>Paul.Domaskis wrote: >> Can anyone suggest how the bash-completion man page is acccessed, and >> what M-/ means? > > M is for "meta", as in the meta escape key functionality in Emacs. > This will work according to the bash command line editing facility, > etc. There are different ways to "make" meta-ness. One, if you > set it up, is to use the Alt shift key. Another is to type the > Escape key then the one that meta is being applied to, in this > case, Escape then / (as two separate key strokes). I think given > this information you can dig up more. I don't know where the > documentation is on the bash completion package, off the top of > my head. >From googling, the meta key is Alt (simultaneously) or Esc (pressed and released before the accompanying key). Using these to try and get M-/, neither combination forces completion. In both cases, the entire command line content is replaced by a forward slash. I thought that the following .inputrc might be causing the problem: .inputrc set visible-stats on set editing-mode vi So I renamed it to something else and launched some new cygwin windows. Puzzlingly, the command line editing behaviour remains unchanged. Not only does completion not work. So find _vim doesn't complete even though _viminfo and _vimrc are present. Similarly using of Alt or Esc for the meta key doesn't result in completion when M-/ is typed. Much more puzzlingly, I can still get vi editing behaviour at the bash command line. Very strange. And the mystery doesn't stop there. If I open up an xterm, the above completion *does* work using just the tab key. Woohoo! Very strange that it would work, though -- it shouldn't! However, the other anomalies are still present in the xterm. That is, using Alt or Esc for the meta key in M-/ results in the entire command line content being replaced by forward slash, and I also can get vi editing behaviour at the bash command line. Curioser and curioser -- 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: No file name completion for file names start with underscore
Andrey Repin yandex.ru> writes: >Paul.Domaskis wrote: >> I think I will need to deepen my knowledge into the bowels of unix. >> This thread is the first I've heard that completion depended on the >> command being typed. Thanks, all. > > That's the reason for bash-completion package. If you remove it, > then the completion will fall back to generic behavior. Interesting. I might un-install bash-completion. But I will first experiment. According to /usr/share/doc/bash-completion/README, I can use M-/ to force completion. For the "M", I unsuccessfully experimented with the Windows key, Alt, and Ctl. Then I tried to seek more details. The source for info about M-/ is described as the man page. However, it's not clear to me how to invoke the man page for bash-completion. The man page for bash should be for the bash-native completion. The cygwin package search doesn't show much for documentation besides /usr/share/doc/Cygwin/bash-completion.README. Can anyone suggest how the bash-completion man page is acccessed, and what M-/ means? Thanks. -- 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: No file name completion for file names start with underscore
Gary Johnson spocom.com> writes: > David is right: find does accept a file name as the path argument. > I didn't know that. (Obviously.) The man page doesn't really say, > but all references to the path argument suggest that it contains a > directory or list of directories. > > Nevertheless, the completion function for find (_find(), in > /etc/bash_completion.d/findutils or > /usr/share/bash-completion/completions/find) does expect that > argument to be a directory and expands only directories. I think I will need to deepen my knowledge into the bowels of unix. This thread is the first I've heard that completion depended on the command being typed. Thanks, all. -- 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: No file name completion for file names start with underscore
Andrew DeFaria DeFaria.com> writes: >On 9/18/2014 11:42 AM, David Boyce wrote: >>> The path argument to find must be a directory. >> >> Sorry, but I can't let this go by. The statement above is >> incorrect, as a simple test like "find /etc/passwd -print" would >> show. > > Or just "find /etc/passwd". (-print has been the default for > decades... The man page it's the default but you should proob) Maybe things have changed. I think Gary Johnson is right. For background, my old 32-bit cygwin 1.7.17-1 install (bash 4.1.10-4), "cygcheck -cvs | grep -i completion" shows no packages with the string "completion" in the name. And if I have files (not directories) _viminfo & _vimrc, tabbing after "find _vi" does a completion up to "find _vim", then shows me the two candidate files thereafter. In my new 64-bit cygwin 1.7.28-2 (bash 4.1.11-2, bash-completion 1.3-1), I also have _viminfo & _vimrc, but "find _vi" doesn't complete, nor does it show candidate files. I ensured that I have directories vimfiles and vimtest, and "find vi" does complete up to "find vim", then shows me the two candidate directories thereafter. On the other hand, in the new 64-bit cygwin, "ls vi" and "ls _vi" *always* completes as much as it can, then shows me the two candidates thereafter. -- 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: No file name completion for file names start with underscore
writes: > writes: >> I'm using the following 64-bit packages: >> >>cygwin 1.7.28-2 bash-completion 1.3-1 >> >> If I am in a folder that contains file _vimrc and directory >> _vimfiles, filename completion doesn't respond. I type "ls _" or >> "ls _v" and press tab -- nothing happens. I can't really do >> anything about it because it took months to approve the use of >> cygwin install CDs made near the beginning of the year, but I was >> wondering the problem is reproducible by others? > > Oops, my bad. The phrase "file _vimrc and directory _vimfiles" should > read "files _vimrc and _viminfo". The directory is actually > "vimfiles" and has no underscore. I'm not sure if this is a false alarm, but I have another error in my original post, due to my haste in cobbling together an arbitrary example. In actuality, completion does not fail for "ls _v". It fails for "find _v". But it works for other commands like ls and find. Again, lack of completion fails only when trying to specify filenames starting with underscore as arguments to the find command. -- 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: No file name completion for file names start with underscore
writes: > I'm using the following 64-bit packages: > >cygwin 1.7.28-2 bash-completion 1.3-1 > > If I am in a folder that contains file _vimrc and directory > _vimfiles, filename completion doesn't respond. I type "ls _" or > "ls _v" and press tab -- nothing happens. I can't really do > anything about it because it took months to approve the use of > cygwin install CDs made near the beginning of the year, but I was > wondering the problem is reproducible by others? Oops, my bad. The phrase "file _vimrc and directory _vimfiles" should read "files _vimrc and _viminfo". The directory is actually "vimfiles" and has no underscore. -- 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
No file name completion for file names start with underscore
I'm using the following 64-bit packages: cygwin 1.7.28-2 bash-completion 1.3-1 If I am in a folder that contains file _vimrc and directory _vimfiles, filename completion doesn't respond. I type "ls _" or "ls _v" and press tab -- nothing happens. I can't really do anything about it because it took months to approve the use of cygwin install CDs made near the beginning of the year, but I was wondering the problem is reproducible by others? -- 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: vi editing at bash command line: cc command doesn't work
Gary Johnson spocom.com> writes: > I have both 32-bit and 64-bit versions of Cygwin installed on a > Windows 7 Enterprise SP1 system. I can confirm that using a Cygwin > Terminal, cc works on the 32-bit installation but not on the 64-bit > installation. > > There is no connection between the vi mode of the bash command line > and Vim. Thank you, Bob & Gary. Looks like an issue with the 64-bit package. Since it is too length a process to get another snapshot approved for internal use, I will just work around that. -- 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: vi editing at bash command line: cc command doesn't work
writes:
> writes:
>> I needed cygwin on a new work computer that was locked down. I
>> created a DVD from all the 64-bit packages some time in the first
>> quarter of 2014, then took the several months needed to get
>> approval for its installation. I then replicated the environment
>> from an old work computer with a 32-bit installation of cygwin,
>> including:
>>~/.inputrc
>>~/.minttyrc
>>~/.bash_profile
>>~/.bashrc
>>/usr/share/vim/vimrc
>>/usr/share/vim/vimfiles
>>
>> Everything works well *except* for the fact that when using vi-like
>> editing at the bash command line, the cc command does not clear the
>> line and enter insert mode. This is the same regardless of whether
>> I am using a mintty or an xterm in X-windows. However, if I invoke
>> vim from either of those 2 environments, cc does work. It also
>> works when I run gvim from xterm, and when I run gvim compiled for
>> Microsoft Windows.
>>
>> What more can I check to try and narrow down the cause of the
>> problem?
<...snip...>
> Please note that when I say cc doesn't work with vi-editing at the
> bash command line, I mean that nothing happens.
>
> Also, I did not clean up the vimrc file because I suspect that there
> is very little chance that it was the culprit. I believed that
> nothing from vimrc is used for vi-editing at the command line. I
> confirmed this just now by renaming /usr/share/vim/vim{rc,files} and
> observing the same problem with vi-editing at the command line.
Just noticing that it also affects the dd command too. That is,
nothing happens.
I'm not sure how many people actually use vi key bindings at the bash
command line. If you do, and you have none of the above problems with
the 64-bit install, could you please chime in so that I know that
there is a solution (even though I may not know what that solution
is).
Thanks.
--
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: vi editing at bash command line: cc command doesn't work
writes:
> I needed cygwin on a new work computer that was locked down. I
> created a DVD from all the 64-bit packages some time in the first
> quarter of 2014, then took the several months needed to get approval
> for its installation. I then replicated the environment from an old
> work computer with a 32-bit installation of cygwin, including:
>~/.inputrc
>~/.minttyrc
>~/.bash_profile
>~/.bashrc
>/usr/share/vim/vimrc
>/usr/share/vim/vimfiles
>
> Everything works well *except* for the fact that when using vi-like
> editing at the bash command line, the cc command does not clear the
> line and enter insert mode. This is the same regardless of whether
> I am using a mintty or an xterm in X-windows. However, if I invoke
> vim from either of those 2 environments, cc does work. It also
> works when I run gvim from xterm, and when I run gvim compiled for
> Microsoft Windows.
>
> What more can I check to try and narrow down the cause of the
> problem?
>
> Below, I have pasted in anonymized content from the above files.
<...snip...>
Please note that when I say cc doesn't work with vi-editing at the
bash command line, I mean that nothing happens.
Also, I did not clean up the vimrc file because I suspect that there
is very little chance that it was the culprit. I believed that
nothing from vimrc is used for vi-editing at the command line. I
confirmed this just now by renaming /usr/share/vim/vim{rc,files} and
observing the same problem with vi-editing at the command line.
--
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
