Does Cygnal allow access to devices under /dev?

[Hamish McIntyre-Bhatty]

Hi there,

Asking as IIRC the Cygnal author (or at least some users) are on this list.

Does anyone know if Cygnal supports access to devices under /dev? If it 
does, I may start using it for my program - the Linuxy paths confuse 
some of my users.


Hamish

--
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: Does Cygnal allow access to devices under /dev?

[Adam Dinwoodie]

On Thu, Feb 24, 2022 at 12:51:08PM +, Hamish McIntyre-Bhatty wrote:
> Hi there,
> 
> Asking as IIRC the Cygnal author (or at least some users) are on this list.
> 
> Does anyone know if Cygnal supports access to devices under /dev? If it
> does, I may start using it for my program - the Linuxy paths confuse some of
> my users.

I expect you're better off asking about Cygnal on the Cygnal mailing
list.  Details at http://www.kylheku.com/cygnal/

Cygnal is not Cygwin, so unless you're asking about something you've
already confirmed is common between Cygwin and the Cygnal Cygwin fork,
it's going to be off-topic for this list.

-- 
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

Patches to findutils 4.9.0-1's updatedb to do locking, allow filenames with spaces & progress monitoring, exclude /dev on Cygwin, etc.

[Dan Harkless]

Howdy.  I posted last August to the Cygwin list about some problems I 
was having with the updatedb script, including that it was taking more 
than 24 hours to complete, and then colliding with the next cron run, 
and that I had no way to monitor progress (short of using Sysinternals 
Process Explorer's very awkward GUI for this).


I'm finally getting around to sending in a patch (to bug-findutils and 
the Cygwin list, to which I'm currently subscribed) to address these 
issues, along with some others, a few of which represent small changes 
in behavior:


1. Changed the direct 'find' -> 'sort' pipelining of the file list to 
instead go to a temporary file first (and then a second one, when 
sorting).  This allows monitoring of progress with 'tail -f'.


2. By default, these .txt and .txt.sort files get deleted on exit (or 
fatal signal), but I've added a --keeptext option which can be set to 
'sort' or 'both' to preserve them, either for debugging purposes, or for 
running special-purpose text-munging/matching scripts on.


3. The script now does locking, outputting its PID to (by default) 
/var/locatedb.running_updatedb_pid (I was first just going to just call 
it locatedb.lock, but I decided to be more user-friendly).  If that file 
exists when another instance starts to run, the script will abort with 
an error.


4. Improved signal-handling, catching more fatal signals.  I also 
changed SIGHUP to not be treated as fatal, in line with most programs.


5. /dev was not being excluded by default on Cygwin, since there we 
can't recognize it by filesystem type.  This was causing some 
time-consuming looping problems for me, with falsely self-nested paths.


6. I tried a whole bunch of different quoting variations, but I couldn't 
get --prunepaths to work with paths containing spaces (which are of 
course very common on Windows).  The PRUNEREGEX would always end up 
incorrectly splitting on the spaces.  I tried to improve the regexp to 
treat '\ ' differently than ' ', but I couldn't get it to work (I'm more 
expert with Perl regexps than POSIX ones).  In the end, I used a 
not-TOO-ugly kludge: in the first sed -e expression, I change '\ ' to 
'///', and then in the last one I change '///' back to ' ' (the 
backslash isn't needed in the regexp).  Of course '///' should never 
appear in a path; I didn't use simply '//' because it's a relatively 
common artifact of path concatenation.


7. make_tempdir() wasn't being used in the current version of findutils, 
so I removed it.


8. Previously, the only protection the script did of the prior version 
of the database was to write to locatedb.n, and then overwrite locatedb 
with it at the end.  This was a problem for me when trying to debug the 
updatedb issues I was having, since, for instance, if you killed the 
'find', it'd still overwrite the old DB with a partial file list.  The 
script now saves the previous version of the DB as locatedb.prev.  This 
is also quite handy when a file you expect to be able to find goes 
missing, in case it disappeared since the last updatedb run.  (I didn't 
address the underlying problem of the script not aborting if 'find' did; 
the bizarre 4-way 'find' construction with file redirection from the 
middle of the if {} is unlike anything I've seen in a shell script before.)


9. I also made some minor changes, including not outputting the full 
script path on errors, standardizing error formatting, putting quotes 
around arguments in errors, and various cleanups and comment improvements.


10. The most significant of the minor changes I made was standardizing 
the indentation, which was all over the place, making it difficult to 
understand some of the code while debugging. Because of that, in 
addition to the attached 'diff -u' patch, here's the output of 'diff 
-uw' to make it easier to review my changes.  My Linux systems use a 
different version of locate, thus I didn't test there, but I think I 
remained platform-agnostic (and also didn't write any code that wouldn't 
work under Bourne/POSIX shell).  BTW, I assign my copyright to GNU (I 
filled out the official form some years ago when I was co-maintainer of 
Wget), and if you feel my self-credit in the author list comment is 
unwarranted, of course feel free to get rid of it.


Here's that 'diff -uw' output (again, 'diff -u' patch attached):
--- updatedb.orig    2022-02-05 09:37:55.0 -0800
+++ updatedb    2022-02-24 03:27:10.749175300 -0800
@@ -15,13 +15,20 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .

-# csh original by James Woods; sh conversion by David MacKenzie.
+# csh original by James Woods; sh conversion by David MacKenzie;
+# cleanup and enhancements by Dan Harkless.

 #exec 2> /tmp/updatedb-trace.txt
 #set -x

+ourname=`basename $0`  # don't verbosely report path to the script in 
errors

+
+stderr() {
+    echo "$ourname: $*" >&2
+}
+
 version='
-updat

pcre regexps in git?

[Anthony Heading]

Hi,
I appreciate this is just a birthday wish-list item, but...

% git grep -P hopeful...
fatal: cannot use Perl-compatible regexes when not compiled with USE_LIBPCRE

It would be lovely (well, at least for me) if this could work.



-- 
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: pcre regexps in git?

[Adam Dinwoodie]

On Thu, Feb 24, 2022 at 04:19:13PM -0500, Anthony Heading wrote:
> Hi,
> I appreciate this is just a birthday wish-list item, but...
> 
> % git grep -P hopeful...
> fatal: cannot use Perl-compatible regexes when not compiled with USE_LIBPCRE
> 
> It would be lovely (well, at least for me) if this could work.

Huh.  I think that used to work, so if it broke, it presumably broke
somewhere during the Cygwin Git build process wrangling I've been doing
of late.  I'll see what I can do to get it working again for you!

Adam
Cygwin Git maintainer

-- 
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: pcre regexps in git?

[Allen Hewes]

> -Original Message-
> From: Cygwin  On Behalf
> Of Adam Dinwoodie
> Sent: Thursday, February 24, 2022 4:32 PM
> To: cygwin@cygwin.com
> Subject: Re: pcre regexps in git?
>
> On Thu, Feb 24, 2022 at 04:19:13PM -0500, Anthony Heading wrote:
> > Hi,
> > I appreciate this is just a birthday wish-list item, but...
> >
> > % git grep -P hopeful...
> > fatal: cannot use Perl-compatible regexes when not compiled with
> > USE_LIBPCRE
> >
> > It would be lovely (well, at least for me) if this could work.
>
> Huh.  I think that used to work, so if it broke, it presumably broke
> somewhere during the Cygwin Git build process wrangling I've been doing of
> late.  I'll see what I can do to get it working again for you!
>

I use Windows git, but my Cygwin grep doesn't complain:

$ uname -a
CYGWIN_NT-10.0-19044 FOUREYES 3.3.4-341.x86_64 2022-01-31 19:35 UTC x86_64 
Cygwin

$ command -v grep
alias grep='grep --color'

$ grep -P allen temp.txt | wc -l
32

$ grep --version
grep (GNU grep) 3.7
Packaged by Cygwin (3.7-2)
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others; see
.

$ cygcheck -c grep
Cygwin Package Information
Package  VersionStatus
grep 3.7-2  OK

Am I missing something?

/allen



Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or 
documents linked to this email, are intended for the addressee and may contain 
information that is privileged, confidential, proprietary, or otherwise 
protected by law. Any dissemination, distribution, or copying is prohibited. 
This notice serves as a confidentiality marking for the purpose of any 
confidentiality or nondisclosure agreement. If you have received this 
communication in error, please contact the original sender.

-- 
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: pcre regexps in git?

[Yasuhiro Kimura]

From: "Anthony Heading" 
Subject: pcre regexps in git?
Date: Thu, 24 Feb 2022 16:19:13 -0500

> Hi,
> I appreciate this is just a birthday wish-list item, but...
> 
> % git grep -P hopeful...
> fatal: cannot use Perl-compatible regexes when not compiled with USE_LIBPCRE
> 
> It would be lovely (well, at least for me) if this could work.

On my 64bit Windows 10 PC `git grep -P` works fine with both cygwin64
and cygwin32.

(Cygwin64)yasu@rolling[1011]% git --version 
~/Work/zsh
git version 2.35.1
(Cygwin64)yasu@rolling[1012]% git grep -P _cygpath  
~/Work/zsh
Etc/ChangeLog-4.1:  Completion/Cygwin/Command/_cygpath,
Etc/ChangeLog-4.1:  Completion/Cygwin/Command/_cygpath,
Etc/ChangeLog-4.3:  Completion/Cygwin/Command/_cygpath,
(Cygwin64)yasu@rolling[1013]%

---
Yasuhiro Kimura

-- 
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: pcre regexps in git?

[Anthony Heading]

On Thu, Feb 24, 2022, at 4:32 PM, Adam Dinwoodie wrote:
> I'll see what I can do to get it working again for you!

Adam, that is so nice of you,  thank you!

On Thu, Feb 24, 2022, at 6:54 PM, Allen Hewes wrote:
> Am I missing something?

yup,  "git grep" not "grep"

On Thu, Feb 24, 2022, at 7:27 PM, Yasuhiro Kimura wrote:
> On my 64bit Windows 10 PC `git grep -P` works fine with both cygwin64 and 
> cygwin32.

... which gave me that sinking embarrassing feeling that maybe I had made my 
own samizdat build of git in a rush one day and left it lying on my path...   
:-O   but I think git checks for plain strings before calling the regex engine

/src/zsh% git grep -P _cygpath
Etc/ChangeLog-4.1:  Completion/Cygwin/Command/_cygpath,
Etc/ChangeLog-4.1:  Completion/Cygwin/Command/_cygpath,
Etc/ChangeLog-4.3:  Completion/Cygwin/Command/_cygpath,
/src/zsh% git grep -P _cygp.th
fatal: cannot use Perl-compatible regexes when not compiled with USE_LIBPCRE

-- 
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: pcre regexps in git?

[Allen Hewes]

> -Original Message-
> From: Cygwin  On Behalf
> Of Anthony Heading
> Sent: Thursday, February 24, 2022 8:45 PM
> To: cygwin@cygwin.com
> Subject: Re: pcre regexps in git?
>
> On Thu, Feb 24, 2022, at 4:32 PM, Adam Dinwoodie wrote:
> > I'll see what I can do to get it working again for you!
>
> Adam, that is so nice of you,  thank you!
>
> On Thu, Feb 24, 2022, at 6:54 PM, Allen Hewes wrote:
> > Am I missing something?
>
> yup,  "git grep" not "grep"
>

Ah ha, sorry for the noise (and more noise?). This doesn't help you, but 
Windows git does work for me:

production-case-dml.git on  master on ☁️  (us-east-1)
🕙 Thu Feb 24 08:49 PM  ❯ git grep -P migrations
.github/PULL_REQUEST_TEMPLATE/new_migration.md:* [] There is an existing 
`migrations/` directory to hold the sql scripts.

$ git --version
git version 2.35.1.windows.2

$ which git
/cygdrive/c/Program Files/Git/cmd/git

I'll butt out now...

/allen



Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or 
documents linked to this email, are intended for the addressee and may contain 
information that is privileged, confidential, proprietary, or otherwise 
protected by law. Any dissemination, distribution, or copying is prohibited. 
This notice serves as a confidentiality marking for the purpose of any 
confidentiality or nondisclosure agreement. If you have received this 
communication in error, please contact the original sender.

-- 
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