Running the following command:
cat <(ssh remotemachine cat remotefile)
*hangs* on cygwin bash while working on linux bash.
Note though that even on cygwin, the individual pieces seem to work, i.e.:
ssh remotemachine cat remotefile>
and
cat <(cat localfile)
both work.
But combining the
aputerguy writes:
> ssh remotemachine cat remotefile>
Note typo above. Should be:
ssh remotemachine cat remotefile
--
View this message in context:
http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983920.html
Sent from the Cygwin list mailing list arch
The problem also seems to affect named pipes:
i.e.
$ mkfifo mypipe
$ ssh remotemachine cat remotefile > mypipe
Segmentation fault (core dumped)
But
$ cat localfile > mypipe
works
(note in both cases I read the pipe in another terminal using: cat < mypipe)
--
View this message in context:
h
OK I got it to work by using 'ssh -n' since I guess otherwise it was waiting
to read from stdin.
Not sure though why it works without '-n' in Linux...
--
View this message in context:
http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983985.html
Sent from the Cygwin lis
And interestingly,
the mkfifo version still dumps core even with 'ssh -n'
I'm confused...
--
View this message in context:
http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983991.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports:
Here is the situation:
Running from a cygwin 1.7 bash terminal:
$ emacs -nw
$emacsclient -nw
*ERROR*: Not using an ASCII terminal now; cannot make a new ASCII frame
$echo $TERM
cygwin
Running from within screen within cygwin:
$ emacs -nw
emacs: standard input is not a tty
$ emacsclient -nw
*
Andy Koppe writes:
> 2010/1/11 aputerguy
>> Note though that there are good reasons why I use ntEmacs and not
>> cygwin Emacs
>
> Such as?
Well 2 main reasons.
First, I use emacs all the time and keep it open my whole session long. Now
sometimes when upgrading cygwin, I hav
I notice that by default LANG is unset.
Is it best to leave it that way or would it be better to set it to something
like LANG=en-US.UTF-8 (or even C)
Note I am using Cygwin ver 1.7
--
View this message in context:
http://old.nabble.com/Should-LANG-be-set-or-left-unset--tp27165212p27165212.htm
> Larry Hall (Cygwin) writes
> On 11/02/2009 01:29 PM, Jeffrey J. Kosowsky wrote:
>> I didn't see any documentation in the What's New/What's Changed
>> document saying that the following no longer works:
>>:
>> For example:
>> $ ls C:
>> ls: cannot access C:: No such file
Corinna Vinschen writes:
> In Cygwin 1.7 you can do this for any subdir in your volume shadow copy:
>
> $ ls -l //?/GLOBALROOT/Device/HarddiskVolumeShadowCopy1/subdir
>
> It just doesn't work for the root directory of a drive due to internal
> path handling restrictions. But there's a simple wo
For backup, I am trying to dump a list of the acl's for the files being
backed up since my backup program doesn't handle the acls.
When I use something like:
find /c -exec getfacl {} \; > mysavefile
It is slow, in part at least because it has to fork a call to getfacl on
each file found.
Is t
I read the materials in "What's New" and the section "Windows Security in
Cygwin" with interest since it describes new authentication potentials.
However, I did not understand the material well enough to know whether 1.7
will allow users to ssh under their own $USERNAME or whether you will always
Running grep on a 20MB file with ~100,000 matches takes an incredible almost
8 minutes under Cygwin 1.7 while taking just 0.2 seconds under Cygwin 1.5
(on a 2nd machine).
The following cases show how grep under 1.7 grinds to a halt as the number
of matches increases.
The data 'testfile' is a pla
Andrew Schulman-3 wrote:
> getfacl -R?
Unfortunately, no '-R' at least on my updated version.
The "-exec ... \+" and the "-print0 | xargs -0" tricks both worked!!!
Thanks.
Timing and comparing the two approaches, it seems like they both use the
same 'user' time but the xargs approach uses only
OK... one small problem.
Every ~4500 lines and (70-80K characters), both of these methods omit the
empty line between the getfacl stanzas. The skipped lines however don't
occur at the same places in the two different methods.
I assume it must be due to buffering of the long line input or somethin
OK. Here is a simple test case:
X=10
while [ $X -gt 0 ] ; do echo "The quick brown fox jumped over the lazy dog"
; let X=X-1; done > testfile
time grep dog testfile | wc
Cygwin 1.5:
real0m0.219s
user0m0.232s
sys 0m0.045s
Cygwin 1.7:
real7m46.575s
user7m14.138s
sys
The mount manpage says:
-p, --show-cygdrive-prefix
show user and/or system cygdrive path prefix
The and/or would suggest you could have different user and system cygdrive
path prefixes active at once, which would potentially be a bit confusing
Also, is there a better way to
In particular, I can't use "mount -p" to distinguish between prefixes that
might have (variable) number of trailing spaces (which is allowed).
--
View this message in context:
http://old.nabble.com/1.7--Can-you-have-multipe-cygdrive-path-prefixes-active-at-once-tp26227605p26227607.html
Sent fro
Jeremy Bopp writes:
> The concern posed by the instigator of this thread is that it can't be
> known from the output of "mount -p" whether or not the spaces which
> follow the listed cygdrive prefix are part of the prefix or padding for
> the outputted columns. It should be pretty rare that some
Jeremy Bopp writes:
> Well, it's a bit of a hack, but you could try something like the
> following:
>
> $ dirname $(cygpath -u C:/)
> This assumes that there is always a C: drive and converts the path to
> the root of that drive into a POSIX path which will include the cygdrive
> prefix. Then d
Changing LC_ALL also solved the problem for me.
But it begs the question of how many other basic and take-for-granted
functions might be affected by this apparent UTF-8 slowdown. And again we,
are not talking about some minor overhead, we are talking about a slowdown
of 1500X or 150,000%
As a
As a newbie to Windoze/ACL security, I am probably missing something.
But...
Why do 'ls and 'find' seem to treat the ACL restrictions differently.
Specifically, 'ls /c/Documents and Settings/Administrators' works
while 'find /c/Documents and Settings/Administrators' returns:
find: `/c/Document
Lee Rothstein wrote:
> Does this not do what's required (barring spaces in the
> "Cygdrive" alternative prefix):
>
> mount -p | gawk 'NR==2 { print $1 }'
Unfortunately, your method would fail if there were *any* spaces in the
pathname. Since regardless of what you say about the lack of "abject
st
I am currently using the following 'sed' one liner.
It should work except in the case where your cygdrive prefix has two or more
spaces in a row followed by the word 'system' or user' followed again by 2
or more spaces. Pretty unlikely but not impossible of course...
mount -p | sed -ne "s/\(.*\S\
Does cygwin have any ability to find/identify NTFS junction points?
This would be useful so that you don't inadvertently mistreat them thinking
they are regular files or directories.
Also, is there any native cygwin utilities with functionality similar to
junction.exe allowing you to make or dele
Corinna Vinschen writes
> Not quite. Directory junctions appear as symlinks. Volume junctions
> are treated as simple directories since they are for all practically
> purposes the same as Unix mount points.
But I still see several issues at least with directory junctions.
1. When I use junction
Actually the behavior is even stranger... renaming and then deleting
junctions creates spurious directories.
echo "This is a test file" >| targetfile
mkdir targetdir
echo "This is a test dir file" >| targetdir/targetdirfile
junction.exe junctionfile targetfile
junction.exe junctiondir targetdir
Corinna writes..
> Try Cygwin 1.7. It recognizes directory junctions as symlinks.
$ uname -r
1.7.0(0.214/5/3)
But don't see any symlinks...
--
View this message in context:
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26270509.html
Sent from the Cygwin list mailing list
Corinna Vinschen writes...
> Indeed, and I can't reproduce this, neither in Cygwin 1.5.25, nor in
> Cygwin 1.7. The only difference between your and my run is that I'm
> using the cmd mklink builtin rather than the junction tool, like this:
> BLODA?
I don't know... I don't have a lot of BLODA o
Corinna writes:
> I'm glad to read that, but I only debugged the problem. The Fedora
> fix was applied by Chris.
Well it works for me too and as the OP of the problem, I extend my thanks to
both of you and all the others who helped in debugging and coming up with
such a quick fix.
My only remai
Corinna writes:
> Uh, I see. Don't use the junction tool, use cmd's mklink instead.
> junction.exe creates directory symlinks which can't be easily recognized
> as directory junctions, at least not using the default technique.
> I'll look into supporting these weird junctions as well.
Thanks. S
I have been googling on junction.exe and mklink.
Since they both create reparse points, in what way are the reparse points
different to the extent that cygwin recognizes those from mklink but not
those form junction.exe.
The nice thing though about junction.exe is that it uses the *nix like '-d'
More generally, could someone point me to a single source that can accurately
compare and contrast the following notions of "links" in cygwin/windoze:
1. Hard links (ln)
2. Soft links (ln -s)
- Old style
- New style
3. Windows shortcuts
4. Junctions created by junction.exe
5. Reparse poin
Corinna Vinschen writes:
>On Nov 9 11:27, aputerguy wrote:
>> The nice thing though about junction.exe is that it uses the *nix like
>> '-d'
>> flag rather than the dos-like '/D' flag that mklink seems to use.
>mklink /d creates a symlink with a dire
And also add to the below list:
10. mklink
--
More generally, could someone point me to a single source that can
accurately compare and contrast the following notions of "links" in
cygwin/windoze:
1. Hard links (ln)
2. Soft links (ln -s)
- Old style
- New style
3.
"DePriest, Jason R." wrote:
> There is also the 'subst' command that lets you create a directory and
> point it to a drive.
OK - now I am truly tearing out my hair as 'subst' makes #11.
I'm thinking a table with the following columns would be very helpful:
A. Name of command
B. Source (e.g., Cyg
Christopher Faylor writes
> It's not clear whom you are expecting to prepare this comprehensive
> list. For Cygwin we clearly want you to use our symlinks. It's a
> bonus that Corinna has implemented any functionality for anything
> else at all.
No real expectations and not a complaint about cy
I'm not sure if this is a bug or a feature.
But I find the following differences between *nix and cygwin on access
permissions of 'ls'
Test case:
$ mkdir -p dir1/dir2
$ chmod 700 dir1
$ ls -d dir1
dir1 [both Linux & Cygwin]
$ ls dir1
ls: cannot open directory dir1 Permission denied [both
Corinna Vinschen-2 writes:
> http://www.google.com/search?q=%22bypass%20traverse%20checking%22
I was unaware of that "feature"
However, after turning it off, it still seems that cygwin 'ls' gives a
different response than *nix 'ls' to a file in the subtree of a directory
that is "non-traversable
Similarly, 'cd' seems to return a different error message on cygwin vs. Linux
when looking at such subdirectories:
$cd dir1
bash: cd: /root/dog: Permission denied [both cygwin & linux]
$ cd dir1/
bash: cd: /dir1/: Permission denied [linux]
bash: cd: dir1/: Not a directory
Am I missing something
Corinna Vinschen-2 writes:
> On Nov 10 07:22, aputerguy wrote:
> > I was unaware of that "feature"
> > However, after turning it off,
> Don't do that. There's more to this user right than you see at first
> sight. A lot of stuff might not work
This is inconsistent with Linux treatment - is that what we want?
Because it would be good to be able to trap this as an error.
$ getfacl sfdsfdsfdsf
getfacl: sfdsfdsfdsf: No such file or directory
$ echo $?
0 (cygwin)
1 (linux)
--
View this message in context:
http://old.nabble.com/getfacl-re
Corinnna writes:
> 2 (solaris). Since getfacl is based on the Solaris tool, I'll implement
> that return code. 1 is returned for usage errors.
Works for me - as long as I can trap it
--
View this message in context:
http://old.nabble.com/getfacl-returns-0-if-no-file-found-tp26287360p26291764
Currently when upgrading the base 'cygwin' package, the installer only warns
you midway through the installation after some files have been
removed/replaced.
If you have other cygwin processes running, you may be left in an incomplete
state where you can't or don't want to kill the other cygwin p
Jeremy Bopp writes:
> BTW, this is not only a problem for the cygwin package. Literally any
> package could have files which are in use at the time of replacement.
> So any solution would need to take that into account.
True but sometimes the perfect is the enemy of the good enough...
The 'cygwi
I would like to clone the cygwin setup from one pc to another.
Looking at the registry, it appears that at least in my case there are only
a few registry entries with the text cygwin in them, including the %path%
and several entries corresponding to the services I have set up (rsyncd,
sshd, XWin)
I guess the other thing to worry about would be ACL entries.
If there are any, I could solve that with getfacl/setfacl assuming that the
ACL changes were addressable by getfacl/setfacl.
And if not I could always use 'subinacl' to just clone the entire ACL
structure of the C:\cygwin tree.
--
View
Corinna VInschen writes:
> For exakt cloning including ACLs, I would suggest to use robocopy. Yes,
> it's a native tool, but it's sort of a swiss army knife to do exactly
> that job. You don't need to copy the registry entries.
Thanks Corinna!
When you say that I don't "need" to copy the regis
I am trying to capture the error messages of 'subinacl.exe' (a dos program
included with Windows 2003 toolkit) which I am running from a bash script.
However both the stderr and stdout of the process seem to go to bash stdout
since redirecting bash stderr (2>) doesn't seem to have any effect.
I
Dave Korn writes:
>Christopher Faylor wrote:
>>
>> Although, hmm, on rereading it isn't clear that the output shows up on
>> the screen. It sounds like the DOS program just might not differentiate
>> between stdout and stderr.
Yes the output (both stderr and stdout) appear on screen
> I chec
This is a weird one.
If I use a non-cygwin program such as 'edit' or 'ntemacs' to create a file
under userA, say 'test', then when I list under user A, I get as expected:
-rwxr--r--+ 1 userA None 0 2009-11-14 19:00 test*
However, when I list under userB (who is non-privileged), I get:
-rwxr--r--
And also the parent directory has the following listing:
drwxr-xr-x 1 userA Administrators 0 2009-11-14 19:10
--
View this message in context:
http://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-other-user-tp26355135p26355136.html
Sent from the Cygwin list mailing lis
And the same thing occurs for directories created from Explorer.
But again this problem doesn't occur for files or directories created within
cygwin (e.g., touch, mkdir, cat >).
--
View this message in context:
http://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-oth
When I log in via ssh (and have the infamous USERNAME=SYSTEM), subinacl
assigns *all* file and directory ownership to "nt authority\system"
getfacl however still gets the ownership right.
I assume this has something to do with the fact that ssh comes in as
USERNAME=SYSTEM but it is a pita that su
Jason DePriest wrote:
> Does 'ls -n' show the UIDs under both users?
ls -n shows uid=gid=4294967295 which I believe is UINT_MAX (2^32-1), so this
is just -1.
Maybe what's happening is that cygwin is returning an error (-1) here?
BTW I'm running cygwin 1.7
--
View this message in context:
http
I find /proc/registry is a nice shortcut for reading registry entries rather
than having to use regtool/reg/regedit etc.
It would be nice though if there were links for the commonly accepted
shortcuts as used for example by regtool.
Any reason not to add them within /proc/registry itself (of cou
For a while, I have been using the "trick" of executing scripts via 'at' when
logged in over ssh to get around the limitations of USRNAME=SYSTEM. This is
necessary for running things like vshadow, dosdev, and apparently subinacl.
While I have written a short script that figures out the nearest mi
And in case anyone is interested, here is a bash function that launches a
command via 'at' at the next minute and returns the number of seconds until
the launch (actually if you are less than 5 seconds before the next minute,
it waits until the minute after so that at has time to setup - you could
Cygwin 1.7 seems to have lost support for NTFS Alternative Data Streams --
which it seems not to either create or read (vs. Cygwin 1.5 behavior) --
specifically,
$ echo "dog" > foo:bar
$ echo "cat" > foo:baz
$ cat foo:bar
dog
$ cat foo:baz
dog
In Cygwin 1.5
$ ls -s foo*
0 foo
$ ls -1s foo:bar
Andy Koppe writes:
> I'd suspect the support for ADSs in 1.5 was rather accidental anyway.
> POSIX programs certainly don't know about them, and you get the rather
> weird situation that "files" like foo:bar can be accessed but don't
> show up in the directory they're in.
Fair point. But also hav
Dave Korn writes...
> So, it just doesn't work, and that's using all MS software; it's not
> going
> to work any better in bash. I think you're probably out of luck here; I
> don't
> know any way to capture direct console output like that (short of some
> sort of
> screen scraper or even if you
Andy Koppe wrote:
2009/11/15 aputerguy:
>> why does
>> cygwin 1.5 seem to encode it as \357\200\272
> What do you mean? 1.5 doesn't know anything about Unicode filenames.
Well I'm using Putty to ssh into my Windows machine running cygwin 1.5
When I do tab completion
OK - I just re-read the ntsec portion of the cygwin manual and found this
paragraph:
> This has the following unfortunate consequence. Consider a service
> started under the SYSTEM
> account (up to Windows XP) switches the user context to DOMAIN\my_user
> using a token created
> directly by ca
I think it should still at least be documented as a change especially since a
deliberate change.
--
View this message in context:
http://old.nabble.com/Seems-like-treatment-of-NTFS-ADS-%28foo%3Abar%29-changed-between-1.5-and-1.7-but-not-mentioned-in-What%27s-Changed-tp26363833p26370924.html
Sent
Corinna Vinschen writes:
> It means it doesn't know the SIDs. They don't show up in /etc/passwd
> and /etc/group.
BUT THEY DO! And they must since why else would doing a trivial 'chmod'
(that doesn't change anything) all of a sudden make them show up.
$ subinacl /noverbose /nostatistic /file
C:
Corinna Vinschen writes:
> In that case, the problem probably occurs because userB has no
> permissions to read the file permissions. Cygwin's chmod creates a
> POSIX compatible ACL, which adds READ_CONTROL permissions for everyone.
That seems to be the case here and would seem to explain it - t
The following behavior differs between Cygwin bash (both versions 3.2.39,
3.2.49) and Fedora/Linux bash (both versions 3.2.33 and 4.0.33):
$ [[ "foo" =~ \\bfoo\\b ]]; echo $?
Cygwin:
1
Linux:
0
Cygwin returns 0 only if I remove the \\b from before and after the word
'foo'
What is going on her
I have been wondering about this for a long time...
The ps command on cygwin and Linux use incompatible options & flags and
display incompatible output formats. Additionally, linux ps is much more
feature rich.
While I could live with fewer features, the incompatibility in basic input
options an
OK - I think I found the answer which is that \b is a GNU extension not
recognized in cygwin.
So, I guess the question now is there an alternative way of recognizing word
boundaries?
In particular, I am trying to match a process id where $proc is a list of
one or more processes (awk'd from ps).
aputerguy writes:
> Perhaps, I could try adding white space as in
> [[ " $proc " =~ " 456 " ]]
> but not sure if that will always work.
Actually it doesn't work.
I guess I could try to try to prepend/postpend something like an 'x' to each
element of $
Just for the record, the following works:
[[ "$proc" =~ (^|[^0-9])$foo([^0-9]|$) ]] ; echo $?
where I use $foo to store the process number I am trying to match against
--
View this message in context:
http://old.nabble.com/Cygwin-bash-regexp-matching-doesn%27t-treat-%22%5Cb%22-properly-tp2650
Dave Korn writes:
> Bash man page for '~=' refers to man regex(3) which refers to man regex(7)
> which describes word boundary markers as below:
>
> $ [[ "foo" =~ [[:\<:]]foo[[:\>:]] ]]; echo $?
> 0
>
> $ [[ "foobar" =~ [[:\<:]]foo[[:\>:]] ]]; echo $?
> 1
Thanks David!
I had actually greppe'd bo
Hugh Myers:
> This might come across as slightly smart-assed, but if you wrote your
> script in Perl, you wouldn't have the platform problem, nor the
> word-boundary problem. True you would have a Perl problem, but that
> would still be several orders of magnitude easier than trying to have
> Li
Larry Hall (Cygwin) wrote:
>
> On 12/29/2010 11:46 PM, Jeffrey J. Kosowsky wrote:
>> When I do an 'ls -al' (or a getfacl) on some files, I get:
>> owner/group = ???/???, implying that the numeric uid/gid are
>> not found in the passwd/group file.
>>
>> This occurs even though I ran:
>>
Csaba Raduly-2 wrote:
>
> On Sun, Jan 2, 2011 at 7:59 AM, aputerguy wrote:
>> If trustedinstaller is a valid file owner then I would like it to show up
>> as
>> the file owner in cygwin so that rsync transfers it over properly.
>> Presumably this would mean ad
Larry Hall (Cygwin) wrote:
>
> On 1/2/2011 9:09 AM, aputerguy wrote:
>> Csaba Raduly-2 wrote:
>>>
>>> On Sun, Jan 2, 2011 at 7:59 AM, aputerguy wrote:
>>>> If trustedinstaller is a valid file owner then I would like it to show
>>>>
76 matches
Mail list logo
