Re: Cygwin 1.7-58 with windows 2008
On 2/17/2016 12:53 AM, Rashi Singhal wrote: Hi , I have a application that is invoked multiple times. Each invocation accesses shared memory for a performing task. This all works with Cygwin1.3 Now We are using Cygwin 1.7-58 with windows 2008 after this The number... Cygwin 1.7.x is actually pretty old. The current version is 2.4.1. You may want to run a test against the current version to see if this solves your problem. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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 1.7-58 with windows 2008
Hi , I have a application that is invoked multiple times. Each invocation accesses shared memory for a performing task. This all works with Cygwin1.3 Now We are using Cygwin 1.7-58 with windows 2008 after this The number of attached processes keeps on increments and due to which system resource gets full. None of the process get detached from shared memory With Cygwin 1.7-58 When I run through my application, it will give successful response for 3 messages out 5 messages and my client application hangs. My Error log file has recorded the following statements: CU-E-3404(3196):Unable to Send Communication Packet (CUP) on Queue. msgsnd-E-3011(3196):EAGAIN No more processes.. Our application uses IPC functionalities for sending and receiving messages from other application. I have made the following configuration for message queue, shared memory and semaphore MSGINFO: MSGMAX:4096 MSGMNI:50 MSGTQL:400 MSGMAP:402 MSGMNB:16384 SEMINFO: SEMMNI:200 SEMMNS:128 SEMMNU:150 SHMINFO: SHMMNI:100 SHMMAX:200 So please... can any one suggest where m going wrong and please give me the possible solutions for it. Your help is really appreciated. -- 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: Possible Security Hole in SSHD w/ CYGWIN?
First let me say that I'm not too well-versed in coding and the ins and outs of how processes utilize credentials when they are spawned. However, the jist of it seems to be that if there are no credentials saved with passwd -R to replace the current user token with that of the user that is SSH'd in, then there is no way to change that token at all (or get rid of it) meaning the token used when accessing a share will stay as the token of the caller - namely cyg_server? Please correct me if I'm way off-base but that seems to be my interpretation of this. If that is the case, it seems this is an unintended side effect of the way CYGWIN and sshd work together, and with the current state of Windows there isn't really a way around it. And that's OK (I can work around it if that's the case), I just wanted to get to the bottom of why this was happening and let people know the situation because I wasn't sure if anyone was aware of this behavior. Thank you very much Erik and everyone else for the help with this. This is my first time posting on these mailing lists and I appreciate people taking the time to reproduce the issue and help work it out. Thanks, David -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Monday, February 15, 2016 4:11 AM To: cygwin@cygwin.com Subject: Re: Possible Security Hole in SSHD w/ CYGWIN? On Feb 14 13:36, Erik Soderquist wrote: > I think the key point is that if no network password is stored using > the "passwd -R" option, then there should be absolutely no network > access at all in the current code/design, not a fall through to the > cyg_server account's network access, regardless of how much or little > network access that account has. The problem is this: I'm not aware of any explicit OS call which allows the process calling CreateProcessAsUser to drop network credentials of the *caller* in the child process running under another user token. In fact, I'm not even aware of any call which allows to drop network credentials even for the calling process, and that would be the wrong thing to do anyway. This is a clear cut case of "I need help" and "Patches gratefully accepted". Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: locate and updatedb
Linda Walsh sent the following at Saturday, February 13, 2016 7:15 AM
>Marco Atzeri wrote: ---
>> On 11/02/2016 19:33, Byron Boulton wrote:
>>> On 2/11/2016 1:18 PM, cyg Simple wrote:
On 2/11/2016 9:00 AM, Byron Boulton wrote:
> Does anyone here have success using `updatedb` and `locate` in
> cygwin? I use `locate` heavily on my Linux machines, but everytime
> I've tried to run `updatedb` on cygwin I've given up and killed the
> process because it is taking too long.
> There's a reason why on linux it is usually set to run when you are asleep.
> ;-)
>
> Is there something wrong with cygwin's implementation of
> `updatedb` making it not work at all or making it slower that on my
> Linux machines? Or are there others who have success using it on
> cygwin?
>
>But it might have to do with disk speed and memory. Laptop drives are
>usually among the slowest.
>
>I ran it just now (this is with MS's Home Essentials real-time
>protection turned on).
>> locate / >/tmp/all
>> wc /tmp/all
> 1479146 4014375 133322318 /tmp/all
>> df .
>
>law.Bliss/bin> time index_files.sh 670592 (process ID) old priority 0,
>new priority 19 44.21sec 15.06usr 28.30sys (98.09% cpu) Filesystem Size
>Used Avail Use% Mounted on C: 949G 585G 365G 62% /
>
>So ~1.4 million files... Using the following exclusions:
> Local+=" /windows/sysnative/."
>
>---(index_files.sh) renice +19 $$ Local="/" if [[ -d
>/windows/sysnative/. ]]; then fi Prunepaths='/.usr /proc /C /B /H /I
>/M /D /P /System[[:space:]]Volume[[:space:]]Information /Windows/CSC
>/pagefile.sys /Music /Pictures /Share /Media /home /Doc /$RECYCLE.BIN
>/cygdrive'
>
>/bin/updatedb --findoptions=-noleaf --localpaths="$Local"
>--prunepaths="$Prunepaths" --netpaths="$Net" Most of those pruned
>files are pruned either due to redundancy or being on a local network
>server...
>
>That's fairly fast vs. the MS-Home Essentials, full malware scan I
>run once a week that takes ~ 8-16 hours (It scans a few of my network
>directories,as well).
>
Processing every file on the drive will be slow just because it's
Windows. Initializing the database with updatedb will require a large
amount of time. There are processes such as AntiVirus intrusion
protection that might make it even slower.
>>> Hmmm, the reason the slowness is particuarly strange to me is that in
>>> place of using `locate` from my cygwin terminal, I have to use a program
>>> called "Everything Search Engine" available at www.voidtools.com. The
>>> first time I install it, it takes maybe a few minutes to index the hard
>>> drive, then every once in a while when I open the program it takes a few
>>> seconds to update the index, but in general the performance for indexing
>>> and searching the index if comparable to `updatedb` and `locate` on a
>>> Linux machine, so it's possible to do on Windows.
>>>
>>> Byron
>>>
>>
>> the time taken from updatedb is mainly due to
>> the execution time of "find" on the disks.
>>
>> It takes ~ 70 minutes for my 500 GB of data,
>> and likely the AV is impacting the execution.
>>
>> I suspect voidtools is using MS disk indexing
>> to speed up the things for it.
This is technically OT since this involved a non-cygwin tool.
find is slow compared with a non-Cygwin tool, specifically dir (cmd.exe).
Compare find with cmd.exe's dir. Note that even with the benefit of
caching (compare the 1st and 3rd times), find takes twice as long as dir.
Comparing cached times (2nd vs 3rd), dir is 3X faster.
$ time cmd /c dir /s /b 'C:\usr' > /dev/null ; \
time find /c/usr > /dev/null ; \
time cmd /c dir /s /b 'C:\usr' > /dev/null
real0m1.326s
user0m0.000s
sys 0m0.047s
real0m2.465s
user0m0.280s
sys 0m2.184s
real0m0.874s
user0m0.000s
sys 0m0.031s
(Note: c:\usr has nothing to do with /usr.)
Here's how I use dir *in the abstract* for drives C: and D:. (Note: the
/a: option of dir lists all files, including hidden ones; /o:n sorts by
name.)
for D in /c /d
do
"$(cygpath "${COMSPEC}")" /c dir /s /b /a: /o:n "$(cygpath -w "$D")"
done | \
tr -s '\r\n' '\n' | \
cygpath -u -f - | \
sed -e '/^$/d' -e 's,/\+,/,g' \
sort -u \
/usr/libexec/frcode > /tmp/updatedb.tmp
chmod --reference /var/locatedb /tmp/updatedb.tmp
mv /tmp/updatedb.tmp /var/locatedb
What I actually do (attached) is more complicated. My script chooses
which directories are scanned, does them in parallel, and prints pretty
messages. I get error message for very long paths (> ~250 bytes). It
works well enough for me; YMMV.
- Barry
Disclaimer: Statements made herein are not made on behalf of NIAID.
updatedb.sh
Description: updatedb.sh
--
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: [ANNOUNCEMENT] dosbox 0.74-2
Greetings, waterlan! > Andrey Repin schreef op 2016-02-16 18:47: >> Greetings, waterlan! >> > I run DosBOX-win32 directly on 64 bit Windows. No need for a Cygwin > POSIX layer here. You could say the same of many packages. If you want to run MinGW or MSYS, go right ahead. If you want to use Cygwin as an environment in and of its own, then the more packages therein the better. >> >>> I agree with you, but I can't see the advantage for DosBOX. >> >> I don't see a disadvantage either. So, what was your problem, again? >> It is not like anyone forcing you to install it, right? > I don't have a problem with it. I was only wondering if anyone would use > it. I would. I have a few programs (namely BP compiler) I need for my old projects. Running VM is not always a fastest option. -- With best regards, Andrey Repin Wednesday, February 17, 2016 01:11:01 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] dosbox 0.74-2
On Tue, Feb 16, 2016 at 12:36 PM, waterlan wrote: > I don't have a problem with it. I was only wondering if anyone would use it. I do have need to use it occasionally, and I am appreciative that it's now included in the Cygwin repository now. I was able to uninstall the old version I had. It's very hard to test 16-bit DOS programs on Windows 7 and Windows 10! - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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: Protobuf string serialization bug with statically linked protobuf 2.5.0
[please don't top-post] Tomasz Wiszkowski writes: > the protobuf package needs to be rebuilt. That package is orphaned. Since you already have it built and are obviously using it, would you like to maintain it? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: Protobuf string serialization bug with statically linked protobuf 2.5.0
I gather this package bug is not exactly interesting here, but i'll
share a final update.
The package is likely built inaccurately, or is linked against library
that changed ABI over time.
Downloading and compiling protocol buffers library manually does not
expose any of the serialization problems.
furthermore, manual compilation does not introduce an artificial
dependency on cygprotobuf.dll library.
the protobuf package needs to be rebuilt.
thank you for your attention, i will not be disturbing the list with
further updates.
--
"My definition of an expert in any field is a person who knows enough
about what's really going on to be scared" - P. J. Plauger
2016-02-11 15:20 GMT-08:00 Tomasz Wiszkowski :
> A brief correction.
>
> I tried to identify further the problem by selectively linking
> libraries. (-Wl,-Bstatic -lprotobuf.dll -Wl,-Bdynamic) and it turns
> out the problem emerges the moment i statically link both protobuf
> _and_ the c++ library. linking everything statically except for libc++
> seems to work just fine.
>
> i checked if protobuf loads cygc++-6 separately, which would easily
> explain the problem, but it does not seem to. the problem clearly
> seems to be interaction between these two.
>
> linking libc++ dynamically resolves the problem, but that would also
> mean shipping the software with artificial add-on... i suspect
> recompilation still might resolve the issue...
>
>
> --
> "My definition of an expert in any field is a person who knows enough
> about what's really going on to be scared" - P. J. Plauger
>
>
> 2016-02-10 10:54 GMT-08:00 Tomasz Wiszkowski :
>> Dear all,
>>
>> I'm having problems with statically linked executables that use
>> protocol buffers.
>> I suspect the problem may be related to incompatibility between
>> std::string implementation used to compile the library vs. current. If
>> that's the case, the problem would likely go away with recompilation
>> of the protocol buffer libraries (protobuf-lite is also exposing the
>> same problem).
>>
>> I have attached a test case as you requested. the example program
>> compiles two variants - one dynamically linked (works fine) and one
>> statically linked that crashes upon first attempt to serialize the
>> protocol buffer.
>>
>> It would be great if someone could take a look and possibly rebuild
>> the static libraries for protocol buffers.
>>
>> Best regards,
>> Tomasz
>>
>> example.proto
>> syntax = "proto2";
>>
>> package example;
>>
>> message ExampleMsg {
>> optional int32 argc = 1;
>> optional string argv0 = 2;
>> };
>>
>> main.cc
>> #include
>> #include
>>
>> #include "example.pb.h"
>>
>> int main(int argc, char** argv) {
>> example::ExampleMsg message;
>>
>> message.set_argc(argc);
>> message.set_argv0(argv[0]);
>>
>> std::cout << "Serializing protocol buffer." << std::endl;
>> std::string serialized;
>> message.SerializeToString(&serialized); // static variant crashes here.
>> std::cout << "Serialized length: " << serialized.length() << std::endl;
>>
>> message.Clear();
>>
>> std::cout << "Deserializing protocol buffer." << std::endl;
>> message.ParseFromString(serialized); // static variant also crashes here.
>> std::cout << "Deserialized content: argc=" << message.argc() << ", argv0="
>> << message.argv0();
>>
>> return 0;
>> }
>>
>> Makefile
>> CFLAGS += -Wall
>> CXXFLAGS := $(CFLAGS)
>> CC = g++
>> LIBS = -lprotobuf.dll
>>
>> all: clean example example-bug
>>
>> example.pb.cc: example.proto
>> protoc --cpp_out=. $^
>>
>> clean:
>> rm -f *.o *.pb.* *.exe*
>>
>> example: example.pb.o main.o
>> $(CC) $(CFLAGS) $^ -o $@ $(LIBS)
>>
>> example-bug: example.pb.o main.o
>> $(CC) $(CFLAGS) -static $^ -o $@ $(LIBS)
--
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: [ANNOUNCEMENT] dosbox 0.74-2
Andrey Repin schreef op 2016-02-16 18:47: Greetings, waterlan! I run DosBOX-win32 directly on 64 bit Windows. No need for a Cygwin POSIX layer here. You could say the same of many packages. If you want to run MinGW or MSYS, go right ahead. If you want to use Cygwin as an environment in and of its own, then the more packages therein the better. I agree with you, but I can't see the advantage for DosBOX. I don't see a disadvantage either. So, what was your problem, again? It is not like anyone forcing you to install it, right? I don't have a problem with it. I was only wondering if anyone would use it. -- Erwin -- 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
Compiled program does nothing, but has 3 processes running in task manager.
Hello. Not sure if this is the right forum. But any help would be appreciated. Like the subject says, I compiled a program and when i run it, it doesn't do anything. But when i check the task manager, there are 3 instances of it running. And it wont let me kill them either. Before i updated to windows 7, the program worked fine. Anyone had this problem before? -- 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: [ANNOUNCEMENT] dosbox 0.74-2
Greetings, waterlan! >>> I run DosBOX-win32 directly on 64 bit Windows. No need for a Cygwin >>> POSIX layer here. >> >> You could say the same of many packages. If you want to run MinGW or >> MSYS, go right ahead. If you want to use Cygwin as an environment in >> and of its own, then the more packages therein the better. > I agree with you, but I can't see the advantage for DosBOX. I don't see a disadvantage either. So, what was your problem, again? It is not like anyone forcing you to install it, right? > I would also > not run Wine or VirtualBox under Cygwin. It only adds slowness. wat -- With best regards, Andrey Repin Tuesday, February 16, 2016 20:46:49 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin/X 64-bit on Window 10
I installed the motif and Xt debuginfo packages. When I start gdb I get following warning (gdb) run Starting program: /cygdrive/c/BPTECH/batches/versn7_2/execs/BATCHES.x [New Thread 8576.0x5e0] [New Thread 8576.0x9dc] [New Thread 8576.0x14d0] warning: the debug information found in "/usr/bin/cygXm-4.dll.dbg" does not match "/usr/bin/cygXm-4.dll" (CRC mismatch). [New Thread 8576.0x10e0] [New Thread 8576.0x57c] [New Thread 8576.0x9cc] [New Thread 8576.0x3c4] [New Thread 8576.0x45c] [New Thread 8576.0x203c] When it crashes, the output of 'where' is given below. #0 to #8 are Xm and Xt functions, #9 was written by us. #0 XmRenderTableCopy (table=0x283f30, tags=tags@entry=0x0, tag_count=tag_count@entry=0) at /usr/src/debug/motif-2.3.4-3/lib/Xm/XmRenderT.c:1709 #1 0x0003fe810a8a in XmFontListCopy (fontlist=) at /usr/src/debug/motif-2.3.4-3/lib/Xm/XmFontList.c:637 #2 0x0003fe7e5411 in InitializeTextStruct (tf=tf@entry=0x600285c10) at /usr/src/debug/motif-2.3.4-3/lib/Xm/TextF.c:7296 #3 0x0003fe7e5917 in Initialize (request=request@entry=0x600286020, new_w=new_w@entry=0x600285c10, args=args@entry=0xa850, num_args=num_args@entry=0x9e10) at /usr/src/debug/motif-2.3.4-3/lib/Xm/TextF.c:7818 #4 0x0003fe619bb1 in CallInitialize ( class=0x3fe8c4440 , req_widget=req_widget@entry=0x600286020, new_widget=new_widget@entry=0x600285c10, args=args@entry=0xa850, num_args=num_args@entry=8) at /usr/src/debug/libXt-1.1.5-1/src/Create.c:226 #5 0x0003fe61a65c in xtCreate ( name=name@entry=0x600284c00 "fixedColumnRow0", class=class@entry=0x0, widget_class=widget_class@entry=0x3fe8c4440 , parent=0x1fe76cc10, parent@entry=0x600285870, default_screen=0x600052680, args=args@entry=0xa850, num_args=num_args@entry=8, typed_args=typed_args@entry=0x0, num_typed_args=num_typed_args@entry=0, parent_constraint_class=0x3fe8b8dc0 , post_proc=post_proc@entry=0x3fe619bf0 ) #0 XmRenderTableCopy (table=0x283f30, tags=tags@entry=0x0, tag_count=tag_count@entry=0) at /usr/src/debug/motif-2.3.4-3/lib/Xm/XmRenderT.c:1709 #1 0x0003fe810a8a in XmFontListCopy (fontlist=) at /usr/src/debug/motif-2.3.4-3/lib/Xm/XmFontList.c:637 #2 0x0003fe7e5411 in InitializeTextStruct (tf=tf@entry=0x600285c10) at /usr/src/debug/motif-2.3.4-3/lib/Xm/TextF.c:7296 #3 0x0003fe7e5917 in Initialize (request=request@entry=0x600286020, new_w=new_w@entry=0x600285c10, args=args@entry=0xa850, num_args=num_args@entry=0x9e10) at /usr/src/debug/motif-2.3.4-3/lib/Xm/TextF.c:7818 #4 0x0003fe619bb1 in CallInitialize ( class=0x3fe8c4440 , req_widget=req_widget@entry=0x600286020, new_widget=new_widget@entry=0x600285c10, args=args@entry=0xa850, num_args=num_args@entry=8) at /usr/src/debug/libXt-1.1.5-1/src/Create.c:226 #5 0x0003fe61a65c in xtCreate ( name=name@entry=0x600284c00 "fixedColumnRow0", class=class@entry=0x0, widget_class=widget_class@entry=0x3fe8c4440 , parent=0x1fe76cc10, parent@entry=0x600285870, default_screen=0x600052680, args=args@entry=0xa850, num_args=num_args@entry=8, typed_args=typed_args@entry=0x0, num_typed_args=num_typed_args@entry=0, parent_constraint_class=0x3fe8b8dc0 , post_proc=post_proc@entry=0x3fe619bf0 ) ---Type to continue, or q to quit--- at /usr/src/debug/libXt-1.1.5-1/src/Create.c:416 #6 0x0003fe61a906 in _XtCreateWidget ( name=name@entry=0x600284c00 "fixedColumnRow0", widget_class=widget_class@entry=0x3fe8c4440 , parent=parent@entry=0x600285870, args=args@entry=0xa850, num_args=num_args@entry=8, typed_args=typed_args@entry=0x0, num_typed_args=num_typed_args@entry=0) at /usr/src/debug/libXt-1.1.5-1/src/Create.c:570 #7 0x0003fe61abd9 in XtCreateWidget (name=0x600284c00 "fixedColumnRow0", widget_class=0x3fe8c4440 , parent=0x600285870, args=0xa850, num_args=8) at /usr/src/debug/libXt-1.1.5-1/src/Create.c:589 #8 0x0003fe7e6511 in XmCreateTextField (parent=, name=, arglist=, argcount=) at /usr/src/debug/motif-2.3.4-3/lib/Xm/TextF.c:10646 #9 0x00010097cfbc in mosprshCreateSpreadsheet (parentFM=0x600280fc0, spreadSheetTitle=0x1009ec40e <__FUNCTION__.12658+126> "Measuring Unit Specification", rowNames=0x6002835b0, columnNames=0x600275b30, cellSize=0, mosprshCheckButtonCallback=0x0) at mosprshx.c:248 Let me know if I can provide additional information from the debugger. Thank you. Girish -- 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: [ANNOUNCEMENT] Updated: ocaml-4.02.3-1
On 2016-01-28 21:28, Yaakov Selkowitz wrote: On 2016-01-05 06:48, Damien Doligez wrote: There is now a flexdll for x86_64. Could you please enable (nat)dynlink there too? I'd missed this piece of news. The upstream flexdll page doesn't mention cygwin-64 as a supported toolchain. Did you do the porting yourself? Anyway, I will prepare a new version of the package with dynlink enabled for cygwin-64. Ping? Damien, While you're at it, I noticed that libasmrun_shared needs a fix similar to libcamlrun_shared. I posted the fixed patch here: https://github.com/cygwinports/ocaml Could you provide a 4.02.3-2 soon? -- Yaakov -- 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: cygwin64 - bash: syntax error near unexpected token `X86'
> I get the expected command not found response in my cygwin64; what do > you get from "dot --help"? > My Apologies, The problem was between the keyboard and chair. I had an errant alias command in my ~/.bashrc pointing 'dot' to c:\program files (X86)/ I don't know why I didn't think of it till just now. Problem solved Thanks, -- -Andrew Louie :wq -- 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: cygwin64 - bash: syntax error near unexpected token `X86'
On Tue, Feb 16, 2016 at 9:11 AM, Andrew Louie wrote: > I type in the command: 'dot' expecting a bash: dot: command not found > and instead I get: > > bash: syntax error near unexpected token `X86' > > the command: 'which dot' returns: > > which: no dot in ($PATH) > > where is bash finding this dot program? > > (I'm trying to run graphviz in cygwin with no luck) I think it's a > cygwin64 issue, beucase it used to work in 32bit cygwin) I get the expected command not found response in my cygwin64; what do you get from "dot --help"? -- Erik -- 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
cygwin64 - bash: syntax error near unexpected token `X86'
I type in the command: 'dot' expecting a bash: dot: command not found and instead I get: bash: syntax error near unexpected token `X86' the command: 'which dot' returns: which: no dot in ($PATH) where is bash finding this dot program? (I'm trying to run graphviz in cygwin with no luck) I think it's a cygwin64 issue, beucase it used to work in 32bit cygwin) Thanks for the help. -- -Andrew Louie :wq -- 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: Unable to use "grep" command in VIM 7.4
Jeremy Leung email.ulster.ac.uk> writes: > I have recently installed the latest version of Cygwin on my Windows 8 laptop, and everything is working as expected. > However the issue I am having is that when I'm in VIM, and try to use the ":grep" command, it says that the > command is not available in this version. > Why is this the case when I can use grep outside of VIM with no issues, and how could I solve this? Have you updated cygwin base and vim recently? In cygwin mintty window type which vim and check output is: /usr/bin/vim In cygwin mintty window type vim In vim type: :!which grep and check you get: /usr/bin/grep In vim type: :version and check +quickfix is included not -quickfix. In vim type: :set grepprg? grepformat? and check these look like: grepprg=grep -n $* /dev/null grepformat=%f:%l:%m,%f:%l%m,%f %l%m You might have to change grepprg in your ~/.vimrc to :set grepprg=grep -n "$@" /dev/null to handle spaces in arguments properly or type "\ " instead of " ". In vim type: :set sh? shq? sxq? sxe? shcf? srr? stmp? and check these look like: shell=/bin/bash shellquote= shellxquote= shellxescape= shellcmdflag=-c shellredir=>%s 2>&1 shelltemp In vim type your grep command and post that from : and the output for more help. You might also want to try vim ":help grep" and use ":vim" aka ":vim[grep]" instead of ":grep" for searching external files. -- 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: mktemp() fails on Wine 1.9.3 + Cygwin 2.5.0-0.2
Hi John,
This looks like a bug in wineserver.
Cygwin strace log show an access error soon after fhandler_base::open()
[main] mktemp 111 fhandler_base::open:
(\??\C:\cygwin\tmp\tmp.kAEScb0yvo, 0x108A02)
[main] mktemp 111 __set_errno: int aclsort32(int, int,
aclent_t*):1403 setting errno 22
[main] mktemp 111 __set_errno: void* set_posix_access(mode_t, uid_t,
gid_t, aclent_t*, int, security_descriptor&, bool):269 setting errno
13
fhandler_base::open() is forwarded to NtCreateFile, but Wine
+relay,+server log show that NtCreateFile seems fine (please ignore
the difference of random file name):
0009:Call
ntdll.NtCreateFile(0060c7d4,c010,0060c7e8,0060c7e0,,0080,0007,0002,4020,,)
ret=6103a45d
0009:trace:ntdll:FILE_CreateFile handle=0x60c7d4 access=c010
name=L"\\??\\C:\\cygwin\\tmp\\tmp.BM21HIw0vU" objattr=0042
root=(nil) sec=(nil) io=0x60c7e0 alloc_size=(nil) attr=0080
sharing=0007 disp=2 options=4020 ea=(nil).0x
0009:trace:file:wine_nt_to_unix_file_name
L"\\??\\C:\\cygwin\\tmp\\tmp.BM21HIw0vU" ->
"/media/workspace/wine-cygwin-1028/dosdevices/c:/cygwin/tmp/tmp.BM21HIw0vU"
0009: create_file( access=c010, sharing=0007, create=2,
options=4020, attrs=0080,
objattr={rootdir=,attributes=0042,sd={},name=L""},
filename="/media/workspace/wine-cygwin-1028/dosdevices/c:/cygwin/tmp/tmp.BM21HIw0vU"
)
0009: create_file() = 0 { handle=00f4 }
0009:Ret ntdll.NtCreateFile() retval= ret=6103a45d
(looks identity to the good version of log, so I won't paste the good
version here)
In this case, comparing +relay,+server log between good case and bad
case doesn't expose enough information, so we might need to compare
Linux strace log from good case and bad case:
[pid 11724] write(2, 0xb7584000, 2440009: create_file(
access=c010, sharing=0007, create=2, options=4020,
attrs=0080,
objattr={rootdir=,attributes=0042,sd={},name=L""},
filename="/media/workspace/wine-cygwin-1028/dosdevices/c:/cygwin/tmp/tmp.2kmv323jLu"
)
[pid 11732] close(9
[pid 11724] <... write resumed> ) = 244
[pid 11732] <... close resumed> ) = 0
[pid 11724] open(0xa3a0e90, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 107
[pid 11724] fstat64(107, {...}) = 0
[pid 11724] fgetxattr(107, 0x80a30e8, 0xbfe5dcec, 65536) = 314
[pid 11724] close(107) = 0
[pid 11724] open(0xa3a0e40,
O_RDWR|O_CREAT|O_EXCL|O_NONBLOCK|O_LARGEFILE, 0555
By comparing to the good case, i found the above open syscall should
open the file as 0666 mode.
Related code below:
https://github.com/wine-compholio/wine-patched/blob/master/server/file.c#L408
226 if (sd)
227 {
228 const SID *owner = sd_get_owner( sd );
229 if (!owner)
230 owner = token_get_user( current->process->token );
231 mode = sd_to_mode( sd, owner );
232 }
233 else if (options & FILE_DIRECTORY_FILE)
234 mode = (attrs & FILE_ATTRIBUTE_READONLY) ? 0555 : 0777;
235 else
236 mode = (attrs & FILE_ATTRIBUTE_READONLY) ? 0444 : 0666;
I need to do more research in order to write test and figure out the
right way to fix this bug, my current guess is Wine's sd/token
emulation is not completed yet, which cause unexpected behavior.
--
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 unable to resolve hostnames
Carl-Erik Kopseng gmail.com> writes: >>> ssh: Could not resolve hostname timbuktu.kopseng.no: Non-recoverable >>> failure in name resolution >> I don't think this is a generic Cygwin problem. I can resolve the >> hostname just fine: >> $ uname -svr >> CYGWIN_NT-10.0 2.4.1(0.293/5/3) 2016-01-24 11:26 >> $ ssh timbuktu.kopseng.no >> The authenticity of host 'timbuktu.kopseng.no (51.175.197.68)' can't be established. >> RSA key fingerprint is SHA256:ddcghrb6BI6+TVDKDE3Yf+U43v9EL6u7HsNw7Hec+y8. >> Are you sure you want to continue connecting (yes/no)? no >> Host key verification failed. > I think it has to do with how Cygwin interfaces with VMs. Perhaps it > has something to do with network tunnelling or something related to > how ip and DNS works when being NAT'ed through VMWare Fusion. > > I am running the Windows 8 VM on VMWare Fusion on OS X 10.11.3 Could it be lack of support for DNSSEC as your domain shows: $ whois kopseng.no % Kopibeskyttet, se http://www.norid.no/domenenavnbaser/whois/kopirett.html % Rights restricted by copyright. See http://www.norid.no/domenenavnbaser/whois/kopirett.en.html Domain Information NORID Handle...: KOP444D-NORID Domain Name: kopseng.no Domain Holder Handle...: CK1990P-NORID Registrar Handle...: REG42-NORID Tech-c Handle..: DH38R-NORID Name Server Handle.: NSHY11H-NORID Name Server Handle.: NSHY46H-NORID Name Server Handle.: NSHY81H-NORID DNSSEC.: Signed DS Key Tag 1...: 42355 Algorithm 1...: 8 Digest Type1...: 2 Digest 1...: 8065b555e0009918e7aba49191e6409481afc702f028c0ff20f1bf27e847e21b http://dnssec-debugger.verisignlabs.com/timbuktu.kopseng.no shows no issues with setup. VMware KB search shows no DNSSEC hits on Fusion, bunch on ESX. Might want to start with https://communities.vmware.com/message/1454999#1454999 and the rest of that thread. You can browse from there to more generic natd, dhcpd, and net config and diag info or RTFM. -- 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: [ANNOUNCEMENT] dosbox 0.74-2
On Tue, Feb 16, 2016 at 8:57 AM, waterlan wrote: > I agree with you, but I can't see the advantage for DosBOX. I would also not > run Wine or VirtualBox under Cygwin. It only adds slowness. There are people who run Cygwin under Wine, so the circle is now complete :) Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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
