monotone-devel
[Top][All Lists]

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

 From: Thomas Keller Subject: Re: [Monotone-devel] Please review nvm.man-page Date: Sat, 21 Aug 2010 20:35:24 +0200 User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6

Am 21.08.10 15:20, schrieb Stephen Leake:
>
>> Am 21.08.10 08:48, schrieb Stephen Leake:
>>> 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
>>
>> 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.

--