From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24369 invoked by alias); 6 Jun 2008 04:46:06 -0000 Received: (qmail 24356 invoked by uid 22791); 6 Jun 2008 04:46:05 -0000 X-Spam-Check-By: sourceware.org Received: from ishtar.tlinx.org (HELO ishtar.tlinx.org) (64.81.245.74) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jun 2008 04:45:48 +0000 Received: from [192.168.3.11] (Athena [192.168.3.11]) by ishtar.tlinx.org (8.14.1/8.12.10/SuSE Linux 0.7) with ESMTP id m564jkWt025289 for ; Thu, 5 Jun 2008 21:45:46 -0700 Message-ID: <4848C0FA.7060108@tlinx.org> Date: Fri, 06 Jun 2008 04:46:00 -0000 From: Linda Walsh User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Patch to allow Cron to use non-POSIX shells like Powershell.exe and CMD.exe References: <2abc9c2d0806050258n18191f38i1188b0e9d83ed7ae@mail.gmail.com> <484842DE.2010804@tlinx.org> <20080605235025.GA29853@ednor.casa.cgf.cx> In-Reply-To: <20080605235025.GA29853@ednor.casa.cgf.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2008-06/txt/msg00109.txt.bz2 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/