public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Paul Moore <p.f.moore@gmail.com>
To: cygwin@cygwin.com
Subject: Re: CYGWIN env variable - glob option
Date: Thu, 20 Feb 2020 14:40:00 -0000	[thread overview]
Message-ID: <CACac1F-HpAfetyi-=A4=fEg1WPNM8ipU7TYEi6OdHKE0vBG+Og@mail.gmail.com> (raw)
In-Reply-To: <CACac1F_8+6mDAarSawsKCVea7FuUDsWc3XseLLpH3zdZTbLC_Q@mail.gmail.com>

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<TAB>*.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 <p.f.moore@gmail.com> 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

      reply	other threads:[~2020-02-20 14:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 16:47 Paul Moore
2020-02-20 14:40 ` Paul Moore [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACac1F-HpAfetyi-=A4=fEg1WPNM8ipU7TYEi6OdHKE0vBG+Og@mail.gmail.com' \
    --to=p.f.moore@gmail.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).