This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fw: 1.7.9-1 path issues

On 10/14/2011 15:33, David Bartlett wrote:
> Recently I updated from a thinkpad T61 to a T410 and installed cygwin on 
> it exactly as I had on the T61. The only
> difference was that on the T61 I had an older version of cygwin installed 
> (I'm not sure which one but it would have been
> from around mid 2009).
> in my .profile i have my HOME variable set as HOME=/home/dcbartlett
> I have other variables set up in my profile that take the HOME value as a 
> root.
> DC_ROOT=$HOME/bcystage/app/xform/DC_Scripts; export DC_ROOT
> DC_ERROR=$DC_ROOT/log; export DC_ERROR
> DC_REFRESH_MSG_FILE="$DC_ERROR/refresh_msgs.txt"; export 
> I have unix scripts that use those variables and they call sqlplus which 
> in turn uses those variables in spool commands.
> The issue is that the logging the unix scripts perform works but the 
> spooling from sqlplus does not.
> If I change the HOME variable to HOME=C:/cygwin/home/dcbartlett the unix 
> logging no longer
> works but sqlplus spooling does.  In both cases I get file not found 
> messages.
> Setting HOME to C:/cygwin/home/dcbartlett worked for both unix and sqlplus 
> on my old laptop (with the older version
> of cygwin). And I don't recall doing anything funky to get that to work. 
> Does anyone have any idea on how I can resolve this without having to 
> create one set of 
> variables for Oracle and one for Unix. I am not sure if this is a cygwin 
> issue or an 
> oracle issue.

This is neither an Oracle nor a Cygwin issue.  Cygwin programs usually
expect and sometimes require Cygwin paths while Windows-native programs,
such as sqlplus, always require Windows paths.

Since your previous Cygwin version (likely in the 1.5.x series), many
changes have been made to how Cygwin handles paths.  The Cygwin
developers never promised that Windows would work with Cygwin tools.
They never attempted to break things intentionally, but it seems you've
been bit by using a bad assumption about path compatibility.

Without seeing your scripts and how they use the variables for their
logging tasks, no one can really say much about what specifically you
can do.  Generally though, don't mix Windows paths with your Cygwin
tools and never mix Cygwin paths with your Windows tools.

I can think of 2 options for your situation:

1) Use relative paths everywhere.
2) Write wrapper functions or scripts for all your Windows-native
programs that get called with these paths.

The first may not work for you if you need to hop around within various
working directories while ensuring that the paths still refer to the
same location.  If you can ensure that your scripts always run all
programs from within a single directory though, this is the easiest
option since you probably won't have to perform any path conversions.

If the first option is not possible, you can wrap all calls to the
Windows-native programs in either functions or shell scripts.  The
wrappers would then be responsible for processing all paths given to
them with cygpath in order to make them something usable by the
Windows-native programs that they call directly.  This will localize the
places where you perform conversions without the need to carry two
versions of every variable containing a path through your scripts.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]