From:	lhall AT rfk DOT com (Larry Hall)
Subject:	Re: Using mount consistently to print
29 Oct 1997 13:00:55 -0800 :
Message-ID:	<2.2.32.19971029142801.00953344.cygnus.gnu-win32@ma.ultranet.com>
Mime-Version:	1.0
To:	vischne AT ibm DOT net, gnu-win32 AT cygnus DOT com

At 10:34 PM 10/28/97 GMT, vischne AT ibm DOT net wrote:
>Larry Hall wrote:
>At 11:46 AM 10/28/97 GMT, you wrote:
>>You might check this out on your system, but I think cygwin bash permits
>>a call of the form:
>>
>>	cat textfile > prn
>>
>>Was this a loophole that you overlooked in the quest to make bash
>>impractical for Windows?
>
>I'm assuming this was meant "tongue in cheek" however I would like to 
>clarify that noone is attempting to make bash impractical for Windows.
>Like everything else, it is evolving at the pace at which people who 
>contribute to it are inclined to fix issues.  The DOS style notation 
>for printing is an artifact of the underlying O/S and is a nice "free-bee"
>for printing at the moment.
>
>In other words, the developers mean to close this `loophole' as well?
>Actually, when Unix programs ask for the name of a printer, using `prn'
>is perfectly valid, and the Unix `lpr' program has no problem with this
>either.  Since it doesn't cause any problems with cygwin, AND SINCE MOUNT
>DOESN'T RECOGNIZE PRN, it is the perfect solution.
>

I cannot speak about Cygnus' plans but I would submit that classifying the 
ability to use "prn" as a "loophole" to be "closed" is not only too harsh but 
probably improper since I expect it would be a major undertaking to attempt 
to disable what is an intrinsic "feature" of the Windows O/S's.  I've heard 
noone make this statement or even suggest this classification.  I wouldn't
get too worked up about "prn" disappearing.  Its not likely to happen IMHO.
As for other Windows capabilities, I think you can expect to see all these
tools working more seamlessly with Windows utilities over time.  It has 
always been my impression that these tools are being put in place to 
supplement the Windows environment to help make porting UNIX programs 
easier.  The fact that there are some inconsistencies in the environment 
right now is just a result of looking at a snapshot of a developing entity.
I submit that there is no benefit to reading more into it than that.
I don't think anyone has seriously conceived the notion that these tools
and/or environment will replace ALL Windows functionality (although it may
be possible to work in this way some day if one wanted to).  Regardless, I
don't think anyone is trying to make the two environments incompatible.


Larry

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -