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

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

[Blair Sutton]

Eric Blake <ebb9@byu.net> writes:

> Why should we patch a cygwin utility to promote the use of a non-cygwin shell?

To increase/improve productivity. To move along with the times.

No one can argue that Powershell isn't a good shell taking some of the
best features of many popular shells before it.

> Sending text files as application/octet-stream makes them harder to read in
> email.  Consider using a text MIME type instead.

> You should fix your mailer to not send duplicate copies of a message when
> writing to a text-only mailing list.

I just used GMails default. I'm not sure if I can do what you want.

> And what's wrong with doing this with what cron already provides:

> * * * * * /cygdrive/c/windows/system32/windowspowershell/v1.0/powershell -
> Command '"c:\documents and settings\blair sutton\my
> documents\windowspowershell\test\test.ps1" one two three'

This doesn't work. Have you tried? Also why not support any shell -
that's what Paul Vixie originally intended right?

> I'm not the cron maintainer, but I hope he doesn't bloat the code for this.

Four extra lines of code is bloat to you?

Perhaps you are being a little sensitive here don't you think?

--
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/

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

[Linda Walsh]

Blair Sutton wrote:
> Eric Blake <ebb9@byu.net> writes:
> 
>> Why should we patch a cygwin utility to promote the use of a non-cygwin shell?
---
	None of the shells are 'cygwin', really, -- they are shells that
took their ideas from close-source Bell-Labs research.  But before they
became open source, Bell labs allowed students to use it for free -- and
it became popular -- eventually clones were developed and even later
eventually, most of the bell labs sources were opened up.

	But how about also doing it for reasons of increasing
  interoperability?  To make cygwin more useful to more people?  To
increase the value of cygwin?  I dunno...bunches of reasons...
Maybe some open-source type will try it and create an open source
clone -- but if they can't use it from cygwin, they might never try
it...by smiting everything closed source, you close off sources of
ideas.  Open source doesn't have a monopoly on good ideas or design.

	Besides, I thought patches were the big thing you guys were
always clamoring for, yet the few times I've seen one submitted, it's been
attacked...

	Is it any wonder why anyone would not want to *even* try to submit
a patch or package?  Like people need that hostility when trying to
help out. I know that attitude keeps me away from submitting code
virtually anywhere -- unless I have it to a level of perfection that it
can be unassailable.  I'm not usually willing to put in that level of
perfection as a 'gift' to someone if I'm fearful of getting critically
reamed.  I'm not always considered sensitive, but when I'm being "open"
enough to "open" my code, I am putting "myself" out there...I don't
need extra crap dumped on me just for trying to 'donate' or 'help out'.

> To increase/improve productivity. To move along with the times.
---

	Yeah...that too...

> No one can argue that Powershell isn't a good shell taking some of the
> best features of many popular shells before it.
---
	Personal: Oh boo! it's another incompatible, close source MS util.
If I wanna use it on anything else, I'm screwed.
Can't put it on linux, or Bsd...that just sucks.  I hate
limited time offers, or limited use-products -- if I like them, I want
to be able to use them as I see fit...but that's not allowed with
MS...though, please forgive me for everything I've said if MS has
made it open-source....no strings...then, just kick me, insult me...
at least I'd deserve it...

	That said -- I know attitude is my own personal stuff and just
cause I don't wanna use it doesn't mean I don't support your right to
use it ... So don't think that I would not want you to be able to use
the shell of your choice, whatever that may be...:-)


> 
>> Sending text files as application/octet-stream makes them harder to read in
>> email.  Consider using a text MIME type instead.
---
	Yeah -- what he said! :-)...first time for everything....

	Hey...I just clicked on the attachment in firefox, and told it to open with a 
text editor -- it opened just fine.  Um...ahhh...went back
to text-only 'Mail'....it wasn't so friendly...but as computer people, shouldn't 
we be able to simply "grok" (read" base 64?)...Our schools are so deficient
these days...


>> You should fix your mailer to not send duplicate copies of a message when
>> writing to a text-only mailing list.
---
	Ya got me on this one -- I only saw one message come onto the
list.  Checked in text-only 'Mail', as well -- no dups there...was it
sent to multiple addresses maybe?  Since I only got one copy on my from
the cygwin list.


> 
> I just used GMails default. I'm not sure if I can do what you want.
---
	I'm not sure how it would send a duplicate...but I don't use
gmail.  But's that's no reason why you shouldn't hack into Google's
mail servers and fix the problem......*cough*....:-)



>> And what's wrong with doing this with what cron already provides:
>> * * * * * /cygdrive/c/windows/system32/windowspowershell/v1.0/powershell -
>> Command '"c:\documents and settings\blair sutton\my
>> documents\windowspowershell\test\test.ps1" one two three'
> 
> This doesn't work. Have you tried? 
---
	Uh.oh, Eric,  you mean you just "assumed" it worked and didn't
test it? (ok, I might have assumed similar).

	I was, in fact curious as to why cron wouldn't "just work" with a different 
shell.  Maybe it's a more general problem or bug - in calling
any win-shell not recompiled for Cygwin?  I.e. if I was to use a win32
compiled version of bash (assuming there was one), maybe it would have
some problems too?


> Also why not support any shell -
> that's what Paul Vixie originally intended right?
> 
>> I'm not the cron maintainer, but I hope he doesn't bloat the code for this.
> 
> Four extra lines of code is bloat to you?
> Perhaps you are being a little sensitive here don't you think?
---
	And Eric's not the meanest of the bunch (no offense Eric!)
Maybe he's been polishing his style...George Bush's idea of
'compassionate[sic] conservatism'  sets such a fine example for
the country...  ;~}


--
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/

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

[Christopher Faylor]

On Thu, Jun 05, 2008 at 12:47:42PM -0700, Linda Walsh wrote:
> Blair Sutton wrote:
>> Eric Blake <ebb9@byu.net> writes:
>>>Why should we patch a cygwin utility to promote the use of a non-cygwin
>>>shell?
>
>None of the shells are 'cygwin', really, -- they are shells that took
>their ideas from close-source Bell-Labs research.  But before they
>became open source, Bell labs allowed students to use it for free --
>and it became popular -- eventually clones were developed and even
>later eventually, most of the bell labs sources were opened up.

I think everyone here is aware of the fact that the majority of the
packages in Cygwin were not designed for Cygwin but they were all
designed for a UNIX platform.  And that is the goal of the project.
Supporting Windows utilities is secondary.  Cygwin endeavors to present
an environment where shells understand "-c" rather than "/c".

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.

cgf

--
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/

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

[Linda Walsh]

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/