Mail Archives: cygwin/2008/06/06/00:46:11
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/
- Raw text -