[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] sh: line 1: winepath: command not found

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] sh: line 1: winepath: command not found
Date: Tue, 13 May 2008 18:05:01 +0200
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

On Tue, May 13, 2008 at 08:18:31AM -0700, James Busser wrote:

> For the past few days I have been poking around GNUmed, running the  
> client from anonymous CVS checkout. My Terminal shell window output  
> includes the line
>       sh: line 1: winepath: command not found
>       (repeated x2)

This is harmless. The wording and happening of the message
cannot usefully be influenced by GNUmed. Its origins are:

GNUmed has a method


which, well, uses several methods to detect external
binaries. It gracefully falls back from method to method
returning "not found" when all methods fail. One such method
is to expand a given path to a binary with help of
"winepath" and check the resulting path for existence. This
is useful when people have Wine installed and used a
Wine-based Windows-like path such as "C:\apps\my_app.exe"
for starting, say, the IFAP index drug database. That path
is fed to winepath which returns something like
"/home/user/.wine/drive_c/apps/my_app.exe" which is then
sanity checked by GNUmed. Now, the way winepath is invoked
on the Mac seems to be via a shell (hence the "sh"). Said
shell then informs us that winepath isn't installed. It'd be
more costly runtime-wise to explicitely check for winepath
before invoking it rather than detecting the error when it
happens (it'd be recursive, too, as we would have to check
for the external binary "winepath" ;-)

During startup GNUmed checks for installed DICOM viewers so
it can decide whether the menu item needs to be disabled.

> After that it is quiet and  
> presumably happy, except when I let my connection lapse and I got the  
> exception handler window from which I could not cleanly exit, and my  
> shell echoed a "line 21" 959 Bus error" line which I point out in case it 
> somehow did not make it into the log
It didn't and it can't as it's at least two levels up the
execution hierarchy.

> and would be of any interest:
It is, indeed. It indicates that the reason for GNUmed
freezing sits somewhere higher up in the stack, Python, the
shell, some associated library or even the Mac kernel.

The log didn't contain helpful information and googling the
error doesn't turn up much of anything useful.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]