Re: [Monotone-devel] Please review nvm.man-page

[Thomas Keller]

Am 21.08.10 15:20, schrieb Stephen Leake:
> Thomas Keller <address@hidden> writes:
> 
>> Am 21.08.10 08:48, schrieb Stephen Leake:
>>> Thomas Keller <address@hidden> writes:
>>> I suggest we leave out the I(). fprintf failing is _not_ a monotone bug;
>>> it's an OS or user problem. I don't see how an I() message would be
>>> helpful. 
>>
>> What about checking for -1 as return code as well, after all this
>> shouldn't be a valid FILE * pointer address anyways, right?
> 
> Note the I() is on the fprintf call, not the popen call.
> 
> IEEE Std 1003.1 says fprintf returning -1 indicates an error. The
> current I() fails precisely if the return code is -1. So allowing -1 is
> the same as not having I().

Ok, sorry, I totally misread that. I thought popen() was returning -1,
but if its fprintf(), then you're of course totally right. I'll just
remove the invariant.

>>> It might be better to disable --formatted on WIN32.
>>
>> I have to figure out first how "native" Win32 can be distinguished from
>> Cygwin and / or mingw, but then this is certainly a good idea. 
> 
> #ifdef WIN32 designates a MinGW build. I meant disable it at build time,
> not runtime.  
> 
> I don't think it's meaningful to distinguish between "native" Win32 and
> MinGW at runtime.

I don't know enough of both, cygwin and mingw. You might be right that
its pointless to disable the command at build time (f.e. for our win32
installer) when a user has cygwin installed and executes it from a
cygwin shell on runtime.

>> I'd even go so far and #ifdef out the complete command, as it is
>> absolutely useless in a plain Windows setup.
> 
> No, there is 'man' for MinGW on sourceforge. I just installed it, and
> it works. Doesn't make 'mtn man' work.
> 
> In monotone.texi, it's easy enough to say "--formatted not supported on
> Win32".

If an additional hint in the documentation is all you're asking for then
this is certainly easy to accomplish :)

> Trying that shed some light on the 'popen' problem; the error message
> about 'can't find nroff' is the one from the DOS shell (cmd.exe), not
> the one from MinGW sh. So 'popen' is running 'cmd.exe', rather than
> 'sh', contrary to the IEEE standard. Which explains why '|' doesn't work
> in MinGW 'mtn man'.

Again, I know almost nothing about win32 in this regard, but I know that
there is some kind of pipe support in cmd.exe, so I guess its just
missing mingw's path to actually find nroff and friends. Maybe some `set
PATH=%PATH%;c:\path\to\detected\mingw` before the actual command call
helps then? It would be easier if mingw would automatically add itself
to the path though or have another environment variable we could just
re-use...

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature