Patch to allow Cron to use non-POSIX shells like Powershell.exe and CMD.exe

Linda Walsh cygwin@tlinx.org
Fri Jun 6 04:46:00 GMT 2008


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/



More information about the Cygwin mailing list