Re: Cygwin Performance and stat()
On Mon, May 31, 2010 at 02:19:52AM +0100, Dave Korn wrote: >>On Sun, May 30, 2010 at 05:03:46PM -0400, NightStrike wrote: >>>There's always room for ingenuity and improvements, isn't there? > >On 30/05/2010 22:39, Christopher Faylor wrote: >>If someone is ingenuous enough to make an improvement it's hard to >>believe that they wouldn't be ingenuous enough to send a patch to >>cygwin-patches. > >No, it isn't. (I'm assuming you meant ingenious rather than ingenuous, >because it doesn't make sense the other way.) Yes, I meant ingenious. Let me clarify that *I* find it hard to believe that someone who constructs a Cygwin patch which they want people to know about wouldn't be able to figure out where to send it, especially if they are *reading* *this* *mailing* *list*. >>Or, if they are ingenous enough but just like to lurk in the cygwin >>mailing list so that they can send private email with secret patches >>then I'd have to suspect the quality of the patch itself. > >That's the same-but-opposite as an argument from authority fallacy. No it isn't. Hey this works pretty well! I'll have to remember this technique. I can't believe I'm having a conversation about nonexistent people with nonexistent patches, but my point was that if someone is not confident in making the patch publicly available then it seems very possible that it is not a great patch to begin with. I guess it's possible that someone just doesn't want to go through the pain of getting the patch accepted. In that case, everyone enjoy your private cygwin stat() patches. cgf -- 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: "command not found"-For All Commands
On 31/05/2010 00:08, Christopher Faylor wrote: > On Sun, May 30, 2010 at 03:36:59PM -0700, physicist25 wrote: >> "I ran cygcheck, its also attached as a .txt file. Notice how I had to add a >> "/" to the command to run it." >> I did this again, same results except now I dont have to use "/" when i >> write "cygcheck", the results of running the command are the same. >> >> http://old.nabble.com/file/p28725344/nocommandswork.txt nocommandswork.txt > > This is what that oddly attached file shows: > > -sh-3.2# cygcheck -s -v -r > cygcheck.out > -sh: cygcheck: command not found > -sh-3.2# cygcheck/ -s -v -r > cygcheck.out > cygcheck: dump_sysinfo: GetVolumeInformation() for drive D: failed: 112 > -sh-3.2# This is just the bizarrest thing I've ever seen. What on earth is going on here that appending a slash could make the difference? Is there any kind of alternative unix-alike system such as msys, mingw, mks or gnuwin installed on the machine? cheers, DaveK -- 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 Performance and stat()
On 30/05/2010 22:39, Christopher Faylor wrote: > If someone > is ingenuous enough to make an improvement it's hard to believe that > they wouldn't be ingenuous enough to send a patch to cygwin-patches. No, it isn't. (I'm assuming you meant ingenious rather than ingenuous, because it doesn't make sense the other way.) > Or, if they are ingenous enough but just like to lurk in the cygwin > mailing list so that they can send private email with secret patches > then I'd have to suspect the quality of the patch itself. That's the same-but-opposite as an argument from authority fallacy. cheers, DaveK -- 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: cygpath behaviour when input is not a path
On 30/05/2010 08:51, Gary wrote: > Since the tool > output is mixed paths and text, I'd hoped cygpath made "intelligent" > guesses about what was and was not likely to be a path. > Well, that is basically what it does; but, being a POSIX tool, the consequence is that it assumes that a colon is just a char like any other in a filename. cheers, DaveK -- 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: Reading /proc/registry/... returns extra char
On 31/05/2010 00:35, Andrey Repin wrote: > I know. Look at windows own regedit and Registry Browser FAR plugin as two > examples. > They do such two-way conversion transparently for user. So does cygwin regtool. What's your problem? cheers, DaveK -- 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: Reading /proc/registry/... returns extra char
On Sun, May 30, 2010 at 17:35, Andrey Repin wrote: > Greetings, Christopher Faylor! > > >> > $ cat >a.dat > >> > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Syst > >> > emBootDevice > > > This trailing NUL character was always there, already with Cygwin 1.5. > > It's part of the file content. If strings are stored with a trailing > > NUL in a file, you don't want Cygwin to remove it for you, right? > > Wrong. The training NULL is a string value terminator for REG_SZ > variables, > also a string separator for REG_MULTI_SZ ones. (Which ends with a spare > NULL) > It must not be exposed to the user. >>> I disagree. When you're using tools like regtool, you're right. But when accessing the registry as *files* via the virtual /proc filesystem, you want the file content. >>> >>>Yep. And I certainly not expect the NULL in text files. You know, not every >>>console program is binary-safe when working with STDIO? Not even cygwin, as >>>we >>>can see in this thread. >>> And the file contains the trailing NUL in REG_SZ and REG_EXPAND_SZ values, and multiple NULs in REG_MULTI_SZ values. >>> >>>That's right and true, when you're working with interface directly, but... >>>all >>>the programs I've used in the past, and all the interfaces, they do not >>>expose >>>trailing NULL to the client application. >>>In this case, /proc/registry is an interface, but cat is the application. > >> NAME >> cat - concatenate files and print on the standard output > >> I don't see anything in cat's description which claims it should know >> that some files are special and should be handled differently. > > I didn't said about cat, but rather about file it reading from. > What do you suppose Cygwin should do with the NULs in REG_MULTI_SZ values? Just remove them? >>> >>>Convert them to appropriate EOL sequences. And back to NULL's on write. As >>>per >>>definition of a text as "multiple strings". >>>You don't need to argue over it, just document it properly :) > >> Converting a NUL to a EOL would be very strange behavior. > > Strange? I don't think so. I expect text data from text file. Not binary > stream. And if the registry were a text file you would be exactly correct in your expectations, but the registry is a binary file with some text embedded in it. >> I don't think you really know what you're asking for. > > I know. Look at windows own regedit and Registry Browser FAR plugin as two > examples. > They do such two-way conversion transparently for user. Because they are purpose built applications designed to work with the binary format of the registry. If you want this kind of behavior under cygwin through the /proc/registry interface you need to write a filter or utility to provide it. It should not be a modification of cat which is intended to read the raw data from is input and write it to its output. > > -- > WBR, > Andrey Repin (anrdae...@freemail.ru) 31.05.2010, <3:29> > > 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 > > -- 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: Reading /proc/registry/... returns extra char
On Mon, May 31, 2010 at 03:35:19AM +0400, Andrey Repin wrote: >Greetings, Christopher Faylor! > >> > $ cat >a.dat > >> > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Syst > >> > emBootDevice > > > This trailing NUL character was always there, already with Cygwin 1.5. > > It's part of the file content. If strings are stored with a trailing > > NUL in a file, you don't want Cygwin to remove it for you, right? > > Wrong. The training NULL is a string value terminator for REG_SZ > variables, > also a string separator for REG_MULTI_SZ ones. (Which ends with a spare > NULL) > It must not be exposed to the user. >>> I disagree. When you're using tools like regtool, you're right. But when accessing the registry as *files* via the virtual /proc filesystem, you want the file content. >>> >>>Yep. And I certainly not expect the NULL in text files. You know, not every >>>console program is binary-safe when working with STDIO? Not even cygwin, as >>>we >>>can see in this thread. >>> And the file contains the trailing NUL in REG_SZ and REG_EXPAND_SZ values, and multiple NULs in REG_MULTI_SZ values. >>> >>>That's right and true, when you're working with interface directly, but... >>>all >>>the programs I've used in the past, and all the interfaces, they do not >>>expose >>>trailing NULL to the client application. >>>In this case, /proc/registry is an interface, but cat is the application. > >> NAME >>cat - concatenate files and print on the standard output > >> I don't see anything in cat's description which claims it should know >> that some files are special and should be handled differently. > >I didn't said about cat, but rather about file it reading from. > What do you suppose Cygwin should do with the NULs in REG_MULTI_SZ values? Just remove them? >>> >>>Convert them to appropriate EOL sequences. And back to NULL's on write. As >>>per >>>definition of a text as "multiple strings". >>>You don't need to argue over it, just document it properly :) > >> Converting a NUL to a EOL would be very strange behavior. > >Strange? I don't think so. I expect text data from text file. Not binary >stream. > >> I don't think you really know what you're asking for. > >I know. Look at windows own regedit and Registry Browser FAR plugin as two >examples. >They do such two-way conversion transparently for user. Ok. I'm done trying to educate. We're not going to be changing Cygwin unless we find that there is a bug in its representation of the data in /proc/registry. If the data is being exactly represented as it is retrieved from the registry API, it is not a bug. Even if there is a bug, we are not going to be translating NUL to EOL. I'm fairly confident that Corinna will back me up on that. cgf -- 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: "command not found"-For All Commands
On Sun, May 30, 2010 at 04:31:01PM -0700, physicist25 wrote: > > >"cygcheck: dump_sysinfo: GetVolumeInformation() for drive D: failed: 112 " >Is the response im getting. >And the next line is the command prompt "-sh-3.2# ". Wow. Here's a new one. The instructions at http://cygwin.com/problems.html say: * Run cygcheck -s -v -r > cygcheck.out and include that file as an attachment in your report. Please do not compress or otherwise encode the output. Just attach it as a straight text file so that it can be easily viewed. The "that file" mentioned in this context is "cygcheck.out". It isn't a screen dump of the comands that you ran. So, to be really clear: We don't care what you typed. The output of what you typed has gone into the file "cygcheck.out". That's what we're interested in. cgf -- 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: Reading /proc/registry/... returns extra char
Greetings, Christopher Faylor! >> > $ cat >a.dat >> > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Syst >> > emBootDevice > This trailing NUL character was always there, already with Cygwin 1.5. > It's part of the file content. If strings are stored with a trailing > NUL in a file, you don't want Cygwin to remove it for you, right? Wrong. The training NULL is a string value terminator for REG_SZ variables, also a string separator for REG_MULTI_SZ ones. (Which ends with a spare NULL) It must not be exposed to the user. >> >>> I disagree. When you're using tools like regtool, you're right. But >>> when accessing the registry as *files* via the virtual /proc filesystem, >>> you want the file content. >> >>Yep. And I certainly not expect the NULL in text files. You know, not every >>console program is binary-safe when working with STDIO? Not even cygwin, as we >>can see in this thread. >> >>> And the file contains the trailing NUL in REG_SZ and REG_EXPAND_SZ values, >>> and multiple NULs in REG_MULTI_SZ values. >> >>That's right and true, when you're working with interface directly, but... all >>the programs I've used in the past, and all the interfaces, they do not expose >>trailing NULL to the client application. >>In this case, /proc/registry is an interface, but cat is the application. > NAME >cat - concatenate files and print on the standard output > I don't see anything in cat's description which claims it should know > that some files are special and should be handled differently. I didn't said about cat, but rather about file it reading from. >>> What do you suppose Cygwin should do with the NULs in REG_MULTI_SZ values? >>> Just remove them? >> >>Convert them to appropriate EOL sequences. And back to NULL's on write. As per >>definition of a text as "multiple strings". >>You don't need to argue over it, just document it properly :) > Converting a NUL to a EOL would be very strange behavior. Strange? I don't think so. I expect text data from text file. Not binary stream. > I don't think you really know what you're asking for. I know. Look at windows own regedit and Registry Browser FAR plugin as two examples. They do such two-way conversion transparently for user. -- WBR, Andrey Repin (anrdae...@freemail.ru) 31.05.2010, <3:29> 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: "command not found"-For All Commands
On 2010-05-30 23:24Z, physicist25 wrote: > > I received exactly the same response! The context was that running cygcheck -s -v -r > cygcheck.out displayed an error on the screen. But see whether a file named 'cygcheck.out' was created. It should contain the output that cygcheck was able to produce. -- 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: "command not found"-For All Commands
"cygcheck: dump_sysinfo: GetVolumeInformation() for drive D: failed: 112 " Is the response im getting. And the next line is the command prompt "-sh-3.2# ". -- View this message in context: http://old.nabble.com/%22command-not-found%22-For-All-Commands-tp28722920p28725578.html Sent from the Cygwin list mailing list archive at Nabble.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: "command not found"-For All Commands
I received exactly the same response! -- View this message in context: http://old.nabble.com/%22command-not-found%22-For-All-Commands-tp28722920p28725551.html Sent from the Cygwin list mailing list archive at Nabble.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: Cygwin Performance and stat()
On Sun, May 30, 2010 at 11:52:45PM +0200, Christian Franke wrote:
>Christopher Faylor wrote:
>> On Sun, May 30, 2010 at 12:51:31PM -0700, Christopher Wingert wrote:
>>
>>> I assume POSIX compatibility. However, I bet there are cases where one
>>> can sacrifice compatibility for performance (configurable with an
>>> environment flag of course).
>>>
>>>
>
>The problem is that POSIX stat() requires to provide all information in
>struct stat. This is expensive: convert ACL into mode, convert filetimes
>into time_t, lookup uids, invent ino,
>Typically applications don't need all info but there is no way to tell
>this to stat().
>
>>> See
>>>
>>> http://marc.info/?l=git&m=122278284210941
>>>
>>> for an example.
>>>
>> Yes, I got what you meant. I think that bypassing Cygwin, assuming you
>> can do something good enough is a remarkably bad idea.
>
>A probably better idea would be to add another stat() variant (this is
>IMO missing in POSIX) to Cygwin which allows to specify which info is
>needed.
>
>Something like:
>
>enum {
> CYGSTAT_MODE = 0x01,
> CYGSTAT_INO = 0x02,
> CYGSTAT_SIZE = 0x04,
> CYGSTAT_ATIME = 0x08,
> ...
>};
>
>int cygwin_stat4(const char *path, struct stat *buf, unsigned needed,
>unsigned *pvalid);
>
>Where 'needed' contains all CYGSTAT_* flags for the stat fields needed.
>If 'pvalid' is != 0, the flags for the valid fields are returned in the
>variable. This can be a superset of 'needed' if some info is available
>for free.
>
>Usage example:
>
>// Get st_size only.
>#ifdef __CYGWIN__
>#define stat_size(p, b) cygwin_stat4(p, b, CYGSTAT_SIZE, NULL)
>#else
>#define stat_size(p, b) stat(p, b)
>#endif
And then you'd have to demonstrate that such an implementation actually
showed a measurable improvement, that it doesn't impact the existing
stat(), and that it would actually be used.
And, of course, as soon as you start talking about implementing
something non-POSIX you have strayed away from the whole point of
Cygwin.
And, also of course, we can get one new idea per message here in the
cygwin mailing list but that doesn't actually cause anything to be
implemented.
cgf
--
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: "command not found"-For All Commands
On Sun, May 30, 2010 at 03:36:59PM -0700, physicist25 wrote: > > >I did send the results of cygcheck...some slight changes since... > >"I ran cygcheck, its also attached as a .txt file. Notice how I had to add a >"/" to the command to run it." > >-sh-3.2# cygcheck -s -v -r > cygcheck.out >-sh: cygcheck: command not found >-sh-3.2# cygcheck/ -s -v -r > cygcheck.out >cygcheck: dump_sysinfo: GetVolumeInformation() for drive D: failed: 112 >-sh-3.2# > > >I did this again, same results except now I dont have to use "/" when i >write "cygcheck", the results of running the command are the same. > >http://old.nabble.com/file/p28725344/nocommandswork.txt nocommandswork.txt This is what that oddly attached file shows: -sh-3.2# cygcheck -s -v -r > cygcheck.out -sh: cygcheck: command not found -sh-3.2# cygcheck/ -s -v -r > cygcheck.out cygcheck: dump_sysinfo: GetVolumeInformation() for drive D: failed: 112 -sh-3.2# That shows you typing the commands but it doesn't show that actual output from the commands. cgf -- 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: "command not found"-For All Commands
On 2010-05-30 22:36Z, physicist25 wrote: > > -sh-3.2# cygcheck -s -v -r > cygcheck.out > -sh: cygcheck: command not found > -sh-3.2# cygcheck/ -s -v -r > cygcheck.out > cygcheck: dump_sysinfo: GetVolumeInformation() for drive D: failed: 112 > -sh-3.2# Run it in a windows "command prompt" instead of in bash: cd \cygwin\bin cygcheck -s -v -r > cygcheck.out There should be hundreds of lines of output in 'cygcheck.out'. -- 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: "command not found"-For All Commands
I did send the results of cygcheck...some slight changes since... "I ran cygcheck, its also attached as a .txt file. Notice how I had to add a "/" to the command to run it." -sh-3.2# cygcheck -s -v -r > cygcheck.out -sh: cygcheck: command not found -sh-3.2# cygcheck/ -s -v -r > cygcheck.out cygcheck: dump_sysinfo: GetVolumeInformation() for drive D: failed: 112 -sh-3.2# I did this again, same results except now I dont have to use "/" when i write "cygcheck", the results of running the command are the same. http://old.nabble.com/file/p28725344/nocommandswork.txt nocommandswork.txt -- View this message in context: http://old.nabble.com/%22command-not-found%22-For-All-Commands-tp28722920p28725344.html Sent from the Cygwin list mailing list archive at Nabble.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: Cygwin Performance and stat()
Christopher Faylor wrote:
On Sun, May 30, 2010 at 12:51:31PM -0700, Christopher Wingert wrote:
I assume POSIX compatibility. However, I bet there are cases where one
can sacrifice compatibility for performance (configurable with an
environment flag of course).
The problem is that POSIX stat() requires to provide all information in
struct stat. This is expensive: convert ACL into mode, convert filetimes
into time_t, lookup uids, invent ino,
Typically applications don't need all info but there is no way to tell
this to stat().
See
http://marc.info/?l=git&m=122278284210941
for an example.
Yes, I got what you meant. I think that bypassing Cygwin, assuming you
can do something good enough is a remarkably bad idea.
A probably better idea would be to add another stat() variant (this is
IMO missing in POSIX) to Cygwin which allows to specify which info is
needed.
Something like:
enum {
CYGSTAT_MODE = 0x01,
CYGSTAT_INO = 0x02,
CYGSTAT_SIZE = 0x04,
CYGSTAT_ATIME = 0x08,
...
};
int cygwin_stat4(const char *path, struct stat *buf, unsigned needed,
unsigned *pvalid);
Where 'needed' contains all CYGSTAT_* flags for the stat fields needed.
If 'pvalid' is != 0, the flags for the valid fields are returned in the
variable. This can be a superset of 'needed' if some info is available
for free.
Usage example:
// Get st_size only.
#ifdef __CYGWIN__
#define stat_size(p, b) cygwin_stat4(p, b, CYGSTAT_SIZE, NULL)
#else
#define stat_size(p, b) stat(p, b)
#endif
Christian
--
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 Performance and stat()
On Sun, May 30, 2010 at 05:03:46PM -0400, NightStrike wrote: >On Sun, May 30, 2010 at 1:07 PM, Christopher Faylor wrote: >>On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher Wingert wrote: >>>I was looking into speeding up stat() performance. ?More specifically >>>bash, ls, test, stat performance. ?I've seen the subject come up >>>before. Git recently implemented a native Win32 work around. ?Are >>>there any cygwin patches around? >> >>If there was a way to make stat() faster why wouldn't it be in the >>source code already? > >There's always room for ingenuity and improvements, isn't there? The OP was looking for an existing patch to the source code. If someone is ingenuous enough to make an improvement it's hard to believe that they wouldn't be ingenuous enough to send a patch to cygwin-patches. Or, if they are ingenous enough but just like to lurk in the cygwin mailing list so that they can send private email with secret patches then I'd have to suspect the quality of the patch itself. Otherwise, OF COURSE we'll take improvements to Cygwin if someone provides them. That's how free software is supposed to work. cgf -- 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: "command not found"-For All Commands
On Sun, May 30, 2010 at 12:39:02PM -0700, physicist25 wrote: >I am running the version I downloaded a couple days ago from the cygwin >website. After installation my Windows7 program compatibility >application told me that cygwin was not installed correctly, after >which I told it to reinstall...and it did but this time the >installation was much faster. I may have missed it but it seems like we're several messages into this discussion and you have not yet sent either cygcheck output (as described in http://cygwin.com/problems.html) or, at a bare minimum, the value of your PATH environment variable. cgf -- 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 Performance and stat()
On Sun, May 30, 2010 at 1:07 PM, Christopher Faylor wrote: > On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher Wingert wrote: >>I was looking into speeding up stat() performance. More specifically >>bash, ls, test, stat performance. I've seen the subject come up before. >>Git recently implemented a native Win32 work around. Are there any cygwin >>patches around? > > If there was a way to make stat() faster why wouldn't it be in the source > code already? > > cgf There's always room for ingenuity and improvements, isn't there? -- 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 Performance and stat()
On Sun, May 30, 2010 at 12:51:31PM -0700, Christopher Wingert wrote: >I assume POSIX compatibility. However, I bet there are cases where one >can sacrifice compatibility for performance (configurable with an >environment flag of course). > >See > >http://marc.info/?l=git&m=122278284210941 > >for an example. Yes, I got what you meant. I think that bypassing Cygwin, assuming you can do something good enough is a remarkably bad idea. But, anyway, if there was something in Cygwin, it would be documented. Otherwise, I doubt that anyone outside of the cygwin developers understands the stat() code well enough to come up with a patch. cgf -- 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: "command not found"-For All Commands
I ran cygcheck, its also attached as a .txt file. Notice how I had to add a "/" to the command to run it. -sh-3.2# cygcheck -s -v -r > cygcheck.out -sh: cygcheck: command not found -sh-3.2# cygcheck/ -s -v -r > cygcheck.out cygcheck: dump_sysinfo: GetVolumeInformation() for drive D: failed: 112 -sh-3.2# http://old.nabble.com/file/p28724417/nocommandswork.txt nocommandswork.txt -- View this message in context: http://old.nabble.com/%22command-not-found%22-For-All-Commands-tp28722920p28724417.html Sent from the Cygwin list mailing list archive at Nabble.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: Cygwin Performance and stat()
I assume POSIX compatibility. However, I bet there are cases where one can sacrifice compatibility for performance (configurable with an environment flag of course). See http://marc.info/?l=git&m=122278284210941 for an example. > On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher Wingert wrote: >>I was looking into speeding up stat() performance. More specifically >>bash, ls, test, stat performance. I've seen the subject come up before. >>Git recently implemented a native Win32 work around. Are there any >> cygwin >>patches around? > > If there was a way to make stat() faster why wouldn't it be in the source > code already? > > cgf > > -- > 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: "command not found"-For All Commands
I am running the version I downloaded a couple days ago from the cygwin website. After installation my Windows7 program compatibility application told me that cygwin was not installed correctly, after which I told it to reinstall...and it did but this time the installation was much faster. Hello! Friend what version (so to speak) of Cygwin are you running? How did you install it? For myself, and I suspect that it may not be appropriate for all, I typically run the actual setup program from the website and follow its urging to download itself to a folder, and then install it. Wait for that to happen and finally check to see if the simple program ls for list files works, and then repeat setup, but do so off-line working from the folder. Then repeat to see if the build utilities like Gcc and friends have arrived. That prompt resembles something from the Beta series of Cygwin or perhaps from one of the terminals that doesn't recognize how BASH constructs a (normal) prompt. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." -- 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 -- View this message in context: http://old.nabble.com/%22command-not-found%22-For-All-Commands-tp28722920p28724299.html Sent from the Cygwin list mailing list archive at Nabble.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: "command not found"-For All Commands
On 30 May 2010 18:48, physicist25 wrote: > I am initiating two ways, 1- using the desktop icon I created and 2-using the > one at start that says mintty. > Their startups screens are "bash-3.2#" and "-sh-3.2$". Does this answer your > question? The result in case 1 is to be expected unless your desktop shortcut contains a '-' argument to tell mintty to invoke bash as a login shell. If bash isn't invoked as a login shell, /etc/profile isn't sourced and the prompt and path (among other things) aren't set up. The default mintty shortcut in the start menu does contain that '-' argument though, which is confirmed by the '-' at the start of the prompt you get. I can only reproduce that by removing /etc/profile though, so it looks like something's gone quite wrong with your install. At this point we'll probably need the cygcheck output as described at http://cygwin.com/problems.html, or you might just want to try reinstalling. Andy -- 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: "command not found"-For All Commands
On Sun, May 30, 2010 at 2:18 PM, physicist25 wrote: > > > I just realized what you ment. Okay, this is how I tried to run a cpp file. > > -sh-3.2# ls c:/cygwin/home > -sh: ls: command not found > -sh-3.2# ls/ c:/cygwin/home > cygwin warning: > MS-DOS style path detected: c:/cygwin/home > Preferred POSIX equivalent is: /home > CYGWIN environment variable option "nodosfilewarning" turns off this > warning. > Consult the user's guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > hello.cpp > -sh-3.2# ls/ /home > hello.cpp > -sh-3.2# g++ hello.cpp -o hello > -sh: g++: command not found > -sh-3.2# g++/ hello.cpp -o hello > : hello.cpp: No such file or directory > : no input files > -sh-3.2# ./hello > -sh: ./hello: No such file or directory > -sh-3.2# > > I have no idea what is going on!!! Hello! Friend what version (so to speak) of Cygwin are you running? How did you install it? For myself, and I suspect that it may not be appropriate for all, I typically run the actual setup program from the website and follow its urging to download itself to a folder, and then install it. Wait for that to happen and finally check to see if the simple program ls for list files works, and then repeat setup, but do so off-line working from the folder. Then repeat to see if the build utilities like Gcc and friends have arrived. That prompt resembles something from the Beta series of Cygwin or perhaps from one of the terminals that doesn't recognize how BASH constructs a (normal) prompt. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." -- 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: "command not found"-For All Commands
I just realized what you ment. Okay, this is how I tried to run a cpp file. -sh-3.2# ls c:/cygwin/home -sh: ls: command not found -sh-3.2# ls/ c:/cygwin/home cygwin warning: MS-DOS style path detected: c:/cygwin/home Preferred POSIX equivalent is: /home CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames hello.cpp -sh-3.2# ls/ /home hello.cpp -sh-3.2# g++ hello.cpp -o hello -sh: g++: command not found -sh-3.2# g++/ hello.cpp -o hello : hello.cpp: No such file or directory : no input files -sh-3.2# ./hello -sh: ./hello: No such file or directory -sh-3.2# I have no idea what is going on!!! -- View this message in context: http://old.nabble.com/%22command-not-found%22-For-All-Commands-tp28722920p28723813.html Sent from the Cygwin list mailing list archive at Nabble.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: base-files: LOGNAME
On 2010-05-30 04:31, John Morrison wrote: Could we do; LOGNAME=$USERNAME export LOGNAME instead? I'm not sure those are always equivalent, but I'm no expert on POSIX. 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: base-files: LOGNAME
On 2010-05-30 04:02, Andy Koppe wrote: That would mean a costly fork() during shell startup. Could this be set in the DLL instead, as happens with the SHELL variable? I'm not sure one more will matter; e.g. USER is set via `id -un`. 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
crontab problem
Hi. I`m using CYGWIN Posix environment under windows xp sp2 (ru) But i have problem with crontab. It didnt start as service anyway. If anythink is unclear let me know. See the attach file. Thanks in advance. Current version -rwxr-xr-x 1 Àäìèíèñòðàòîð root 5304 Feb 16 06:14 /usr/share/doc/Cygwin/cron-4.1-59.README Running crons: None Sendmail: lrwxrwxrwx 1 Àäìèíèñòðàòîð Îòñóòñòâóåò 16 May 30 21:55 /usr/sbin/sendmail -> /usr/bin/cronlog Crontabs: cron.log: cron.pid: Crontab: Windows Application Events log: Cygcheck: Cygwin Configuration Diagnostics Current System Time: Sun May 30 22:16:52 2010 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\step\usr\local\bin C:\cygwin\step\bin C:\cygwin\step\bin C:\cygwin\step\usr\X11R6\bin c:\Program Files\Windows Resource Kits\Tools\ c:\Perl\site\bin c:\Perl\bin c:\Python26\ c:\p\site\bin c:\p\bin c:\Perl\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\WINDOWS\system32\WindowsPowerShell\v1.0 c:\Program Files\QuickTime\QTSystem\ c:\Program Files\Nmap C:\cygwin\step\lib\lapack Output from C:\cygwin\step\bin\id.exe (nontsec) UID: 500(Àäìèíèñòðàòîð) GID: 513(Îòñóòñòâóåò) 0(root) 513(Îòñóòñòâóåò)544(Àäìèíèñòðàòîðû) 545(Ïîëüçîâàòåëè) Output from C:\cygwin\step\bin\id.exe (ntsec) UID: 500(Àäìèíèñòðàòîð) GID: 513(Îòñóòñòâóåò) 0(root) 513(Îòñóòñòâóåò)544(Àäìèíèñòðàòîðû) 545(Ïîëüçîâàòåëè) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'Àäìèíèñòðàòîð' PWD = '/bin' CYGWIN = 'ntsec' HOME = '/home/Àäìèíèñòðàòîð' MAKE_MODE = 'unix' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' HOSTNAME = 'sweet-girl' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 4 Stepping 9, GenuineIntel' TERM = 'cygwin' WINDIR = 'C:\WINDOWS' QTDIR = '/usr/lib/qt3' USERDOMAIN = 'SWEET-GIRL' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' OS = 'Windows_NT' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' TEMP = '/cygdrive/c/DOCUME~1/9335~1/LOCALS~1/Temp' TVDUMPFLAGS = '8' QTJAVA = 'C:\Program Files\QuickTime\QTSystem\QTJava.zip' USERNAME = '¤¬¨¨áâà â®à' PROCESSOR_LEVEL = '15' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Documents and Settings\¤¬¨¨áâà â®à' QMAKESPEC = '/usr/lib/qt3/mkspecs/cygwin-g++' !C: = 'C:\cygwin\step\bin' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '2' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1;.py;.pyw' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' PROMPT = '$P$G' SYSTEMROOT = 'C:\WINDOWS' TMP = '/cygdrive/c/DOCUME~1/9335~1/LOCALS~1/Temp' PROCESSOR_REVISION = '0409' CVS_RSH = '/bin/ssh' PRINTER = 'Îòïðàâèòü â OneNote 2007' CLASSPATH = 'C:\Program Files\QuickTime\QTSystem\QTJava.zip' PROGRAMFILES = 'C:\Program Files' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' NUMBER_OF_PROCESSORS = '2' COMPUTERNAME = 'SWEET-GIRL' MYFILES = 'C:\DOCUME~1\9335~1\LOCALS~1\APPLIC~1' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin + Metasploit HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin + Metasploit\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin + Metasploit\mounts v2\/ (default) = 'C:\msf3' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin + Metasploit\mounts v2\/usr/bin (default) = 'C:\msf3\bin' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin + Metasploit\mounts v2\/usr/lib (default) = 'C:\msf3\lib' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin + Metasploit\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin\step' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin\step/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin\step/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin + Metasploit HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin + Metasploit\mounts v2 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin + Metasploit\Program Options c: hd NTFS119718Mb 81% CP CS UN PA FC d: fd N/AN/A e: fd N/AN/A f: fd N/AN/A g: fd N/A
Re: "command not found"-For All Commands
I am initiating two ways, 1- using the desktop icon I created and 2-using the one at start that says mintty. Their startups screens are "bash-3.2#" and "-sh-3.2$". Does this answer your question? -- View this message in context: http://old.nabble.com/%22command-not-found%22-For-All-Commands-tp28722920p28723613.html Sent from the Cygwin list mailing list archive at Nabble.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: Cygwin Performance and stat()
On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher Wingert wrote: >I was looking into speeding up stat() performance. More specifically >bash, ls, test, stat performance. I've seen the subject come up before. >Git recently implemented a native Win32 work around. Are there any cygwin >patches around? If there was a way to make stat() faster why wouldn't it be in the source code already? cgf -- 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: "command not found"-For All Commands
physicist25 wrote: > > Hello, I have recently downloaded cygwin with the hope of learning c++ for > school.the download completed with no problems at all. I installed some > packages such as gcc4, util-linux, ncurses devel, pcre devel, openssl devel, > zlib devel, mintty etc. > > Some Info: > -My machine is a Toshiba L505 Satellit running Windows 7 Ultimate. > -My programming experiance is limited to MATLAB > > Now my problem is that I get the response "command not found" for any > commands other than echo on/off. I googled my heart away and found some > articles that I think are related, as a result I added a path to cygwins bin > by going through control panel. I didnt seem to work. > > Some issues I found in common with others on the web is that typing > -sh-3.2# ls > -sh: ls: command not found > -sh-3.2# How are you invoking your Cygwin session? Andy -- 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
"command not found"-For All Commands
Hello, I have recently downloaded cygwin with the hope of learning c++ for school.the download completed with no problems at all. I installed some packages such as gcc4, util-linux, ncurses devel, pcre devel, openssl devel, zlib devel, mintty etc. Some Info: -My machine is a Toshiba L505 Satellit running Windows 7 Ultimate. -My programming experiance is limited to MATLAB Now my problem is that I get the response "command not found" for any commands other than echo on/off. I googled my heart away and found some articles that I think are related, as a result I added a path to cygwins bin by going through control panel. I didnt seem to work. Some issues I found in common with others on the web is that typing -sh-3.2# ls -sh: ls: command not found -sh-3.2# Refering to a discussion on ls responding with "command not found" (http://cygwin.com/ml/cygwin/2002-10/msg00136.html) I looked in my bin to see if ls is there...it is! I looked in my bin to see if fileutls is there...its NOT and I couldnt find it on the packages list. Looking at the packages list I found that fileutls is located in the package coreutils and when I went to update cygwin it gives me the option of keeping this package...which means I have it, so what am I doing wrong. Some other thoughts, typing ls...like I stated earlier yields the response command not found... but ls/ lists the files I see in bin.so does /usr/bin/ls. -- View this message in context: http://old.nabble.com/%22command-not-found%22-For-All-Commands-tp28722920p28722920.html Sent from the Cygwin list mailing list archive at Nabble.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
Cygwin Performance and stat()
I was looking into speeding up stat() performance. More specifically bash, ls, test, stat performance. I've seen the subject come up before. Git recently implemented a native Win32 work around. Are there any cygwin patches around? Thanks, Chris -- 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: Updated: {pstoedit/libpstoedit0/pstoedit-devel}-3.50-1: pstoedit translates PostScript and PDF graphics into other vector formats
Obkb! Parking now!
Sent from my BlackBerry® wireless device.
D. Ross
-Original Message-
From: "Dr. Volker Zell"
Date: Sun, 30 May 2010 14:21:31
To:
Subject: Updated: {pstoedit/libpstoedit0/pstoedit-devel}-3.50-1: pstoedit
translates PostScript and PDF graphics into other vector formats
Hi
New versions of 'pstoedit/libpstoedit0/pstoedit-devel' have been uploaded to a
server near you.
o Build for cygwin 1.7 with gcc-4
pstoedit NEWS:
===
* added an option (-gs) to specify the full path to GhostScript (under
Windows - either the .exe or the DLL). This can be used by portable
applications to direct pstoedit to use a specific GhostScript version.
* Stanislav Brabec contributed several improvements to the PCB driver. See
http://www.penguin.cz/~utx/pstoedit-pcb/ on how these can be useful.
* Scott Pakin submitted several improvements to the mpost driver and the font
substitution mechanism.
* new driver for .vtk files e.g. for ParaView - http://www.paraview.org/ -
but this is still a very basic version. Thanks to Mitesh Patel for initiating
and testing.
* new driver for cairo (http://cairographics.org/ ) contributed by Dan
McMahill. This driver generates C-code which can be compiled and linked against
the cairo libraries. See the contrib/cairo directory for an example.
* several improvements on the DXF driver as suggested and sponsored by Markus
Meyer.
* because pstoedit may write its output to stdout, all output written by
GhostScript to stdout is now redirected to stderr in order to avoid mixed
output.
* added a -q option to suppress the initial startup message of pstoedit. This
can by useful when being called via a pipe, e.g. from inkscape. However, note
that this does not suppress all output written to stderr - see also note above.
* John Bowman fixed a number of problems related to clipping and image
support for the Asymptote backend.
* fixed a compilation problem with g++ V4.x.
* new driver for gcode (.ngc files) (tested with emc see
http://linuxcnc.org). Contributed by Lawrence Glaister.
* some adaptations for newer versions of libming
* fixed a line width problem for xfig format.
* corrected the broken pstoedit.m4 - thanks to Ian Abbott
* some minor code beautifying.
CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:
http://cygwin.com/lists.html#subscribe-unsubscribe
If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message. Send email to the address specified
there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available
starting at this URL.
[ANNOUNCEMENT] Updated: {pstoedit/libpstoedit0/pstoedit-devel}-3.50-1: pstoedit translates PostScript and PDF graphics into other vector formats
Hi New versions of 'pstoedit/libpstoedit0/pstoedit-devel' have been uploaded to a server near you. o Build for cygwin 1.7 with gcc-4 pstoedit NEWS: === * added an option (-gs) to specify the full path to GhostScript (under Windows - either the .exe or the DLL). This can be used by portable applications to direct pstoedit to use a specific GhostScript version. * Stanislav Brabec contributed several improvements to the PCB driver. See http://www.penguin.cz/~utx/pstoedit-pcb/ on how these can be useful. * Scott Pakin submitted several improvements to the mpost driver and the font substitution mechanism. * new driver for .vtk files e.g. for ParaView - http://www.paraview.org/ - but this is still a very basic version. Thanks to Mitesh Patel for initiating and testing. * new driver for cairo (http://cairographics.org/ ) contributed by Dan McMahill. This driver generates C-code which can be compiled and linked against the cairo libraries. See the contrib/cairo directory for an example. * several improvements on the DXF driver as suggested and sponsored by Markus Meyer. * because pstoedit may write its output to stdout, all output written by GhostScript to stdout is now redirected to stderr in order to avoid mixed output. * added a -q option to suppress the initial startup message of pstoedit. This can by useful when being called via a pipe, e.g. from inkscape. However, note that this does not suppress all output written to stderr - see also note above. * John Bowman fixed a number of problems related to clipping and image support for the Asymptote backend. * fixed a compilation problem with g++ V4.x. * new driver for gcode (.ngc files) (tested with emc see http://linuxcnc.org). Contributed by Lawrence Glaister. * some adaptations for newer versions of libming * fixed a line width problem for xfig format. * corrected the broken pstoedit.m4 - thanks to Ian Abbott * some minor code beautifying. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: base-files: LOGNAME
On Sun, May 30, 2010 10:02 am, Andy Koppe wrote: > On Sunday, May 30, 2010, Yaakov wrote: >> POSIX.1[1] describes a LOGNAME environment variable which represents the >> user's login name. Adding the following lines to /etc/profile should do >> the trick: >> >> LOGNAME="`logname`" >> export LOGNAME >> >> Where logname(1) is a program supplied by coreutils whose presence is >> required by POSIX.1[2]. > > That would mean a costly fork() during shell startup. Could this be > set in the DLL instead, as happens with the SHELL variable? Could we do; LOGNAME=$USERNAME export LOGNAME instead? J. -- 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: base-files: LOGNAME
On Sunday, May 30, 2010, Yaakov wrote: > POSIX.1[1] describes a LOGNAME environment variable which represents the > user's login name. Adding the following lines to /etc/profile should do the > trick: > > LOGNAME="`logname`" > export LOGNAME > > Where logname(1) is a program supplied by coreutils whose presence is > required by POSIX.1[2]. That would mean a costly fork() during shell startup. Could this be set in the DLL instead, as happens with the SHELL variable? Andy -- 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
base-files: LOGNAME
POSIX.1[1] describes a LOGNAME environment variable which represents the user's login name. Adding the following lines to /etc/profile should do the trick: LOGNAME="`logname`" export LOGNAME Where logname(1) is a program supplied by coreutils whose presence is required by POSIX.1[2]. Could base-files please be patched accordingly? Yaakov [1] http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html [2] http://www.opengroup.org/onlinepubs/9699919799/utilities/logname.html -- 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: cygpath behaviour when input is not a path
Andy Koppe wrote: > On 29 May 2010 16:20, Gary wrote: > Have you got any particular reason for overriding the > locale charset with the -C option? Not particularly. I was just reusing the example from http://www.cygwin.com/cygwin-ug-net/using-utils.html I don't think what I want to do is going to work, TBH. It goes back to a previous thread about using "DOS" tools from inside Cygwin's emacs and the resulting path-style clash. Someone (I think it was you, actually) suggested script should handle the paths spewed out from the tool, converting them to Cygwin/Unix style paths. It looks like cygpath tries to convert every line of (for example) '-f -' though. Since the tool output is mixed paths and text, I'd hoped cygpath made "intelligent" guesses about what was and was not likely to be a path. -- Gary Non-kook (allegedly) -- 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
