Christopher Faylor wrote:
Cygwin endeavors to present an environment where shells understand "-c" rather than "/c".
---- I did not look at the change. My initial gut reaction on that change was...no way..."/" is a path character, and it's because Bill Gates wanted to look different from CP/M, so he wouldn't be less likely to be accused of "copying" look&feel...he went with the first *unreasoned*, and *unthinking* thing that popped into his head -- the "literalizing" character in what was already the system programming language in unix and had been, for years -- (I think that's why CPM used it, indirectly)... So basically, because unix used it, he went exactly backwards -- making programming for MS's OS inherently more error prone than other OS's. His own OS and programs are (or were) written mostly in C and C++ -- totally screwing himself and all programmers having to deal with his caca doodoo.
They almost ... had a brief period of sanity in, I think Win98-- when they had a undocumented 'SWITCHCHAR' ENV var -- if you set it to "-", (default was "/"), it would automatically allow use of "/" in pathnames. I hoped, they'd change defaults, and get with the program, but...noooOOOo... I think it was in response to commercial Unices -- even linux, that had them drop the idea and stay as incompatible as possible....idiots. But...I dunno...maybe a SWITCHAR env var could be examined in cron (or something similar)... I just don't like rejecting compatibility options 'out-of-hand' if it's possible to let everyone "have their way". Though that switchchar really gets my goats up... (:-| )
So, while there's no reason to just automatically reject a patch which changes that behavior, there is certainly reason to be skeptical about patch which introduced non-UNIX behavior since it obviously goes against the whole reason for the project.
--- If it hurts the design goals of the project, I agree...if it can be done "orthogonally"...(meaning cleanly and without negatively affecting current cygwin features), then I'm all in support of cygwin being all things to all people....well...that might be stretching it a tad...ok, more than a tad...but still...the more people using it, the better... The more people who use cygwin in a windows environment, the better it is for 'free software', since more will become familiar with gnu-tools... That makes *nix all the more comfortable for folks and works in little ways at loosing the 'grip' of MS's attempt to get their customers working as differently as possible from *nix tools and to make their customers feel that *nix tools are 'alien' or inherently difficult, or arcane...well, maybe some are, a bit...but maybe you get the drift...:-)? But as the discussion is going -- if it can be done within the current cron framework...all the better. For reasons of wanting network shares, running with the correct security-blob duplicating my login session, I use the windows scheduler to run cron tasks like 'cron.daily, cron.hourly... cron.monthly...etc. I do all my maintenance through bash shells, but they are started by the windows scheduler. So I don't see why it shouldn't be possible to fudge/kludge the opposite -- and you're right -- spawning an extra process is insignificant. My nightly jobs index my local disks and network shares (findutils), dump the registry hives to my home-dir, then rsync-backup home dir to a linux server (which gets nightly tower-of-hanoi incrementals. The disk is cleaned of old temp files, is defrag'ed in boot mode and regular mode twice (2nd, after registry and find-util dump files have been created to ensure they're also "clean"). So...um...yeah, the cost of starting an extra shell is *waay* insignificant. :-)... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/