This is the mail archive of the 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: [Fwd: Re: perl test fails]

Hooray, we're there! Thank you!

The -x operator works perfectly, but the problem was still rather obscure, so here's the answer.

Cygwin 1.3.22-1 under NT4, Perl 5.8.0

My script was almost identical to the one Elfyn supplied below, it just tested a local file rather than /usr/bin/perl.


if ( -x "script" )
  print "script is executable\n";

This local file was a one-liner containing only

echo "I damn well am!"

I had chmod +x this file and when I ran either it or my perl script at the command prompt I got the output "I damn well am!", indicating that the -x operator considered the file to be not executable, but the file itself could, actually, be executed.

But Elfyn's script worked, and mine didn't, so I started poking around.

To my surprise I found that the local file had 644 permissions, not 744 as I'd expected. I chmod +x it again, but the permissions didn't change, though I could still run it and get the echoed output. I tried chmod 777, still with no effect. Only when I added a first line #!/bin/bash would chmod +x work, after which my perl script worked just like Elfyn's

So there seems to be a couple of weensy buggettes there, though I'm not suggesting anyone bother to fix them unless they happen to be working there anyway. They're not serious bugs, but they did obscure the real problem and waste quite a lot of my and several other people's time.

1. chmod should surely change the permissions whatever the contents of the file, and if it doesn't, it should issue a message. Silent failure is not very friendly.

2. a file without execute permission shouldn't execute.

Anyhow, thanks for all the responses.

Elfyn McBratney wrote:
Rob Clack wrote:

Well I thought maybe I'd better just try setting $CYGWIN, even though it didn't seem relevant (I don't have "..problems with NT shares or Samba drives..", since the script reliably breaks when run from a local, non-shared drive) and indeed, it made no difference. Unless there's some special way I should be setting it. I just entered CYGWIN=nosmbntsec at the dollar prompt.

OK, so if I assume by the silence that -x is broken, can anyone suggest how I can determine in a perl script whether or not a file is executable?

The `-x' operator WFM.  Does, say, this script fail for you (make sure perl
is *actually* executable) ?


  if (-x "/usr/bin/perl") {
    print "yupp, perl is executable.\n";
  } else {
    print "ut-oh! perl isn't executable.\n";

If you haven't already posted cygcheck[1] output, that might help, and also
post your script (I couldn't find it in my archives).  Sorry if you've
already done this.

-- Elfyn

[1] non-inline, plain-text attachment, as per <>

------------- hyphens to separate this from previous posts -------------

Thank you Igor.  However, I've now read the entry on smbntsec and it
doesn't seem relevant.  (Was a useful exercise in itself, since I didn't
know about the CYGWIN env var either ;)) I don't have a problem on the
Linux box, only on the NT one. And it doesn't matter whether I'm running
the script from the networked drive or from the local hard drive, I only
get the error under Cygwin.

So far it keeps looking to me as though Cygwin is broken.

Igor Pechtchanski wrote:

On Wed, 27 Aug 2003, Rob Clack wrote:

Hmmm, don't see how it can have anything to do with the mapping of a
networked drive, since the problem started on the NT4 box, at which time
the scriptlet was located in /cygdrive/e/cygwin/rnc/try.

Since I wanted to demonstrate that it worked on the Linux box (having
tripped over that one originally!)  each time I hacked one copy of the
script I then had to move to the other machine and duplicate the changes
I'd just made.  Clearly this was error-prone, so it made sense to just
use the copy on the Linux box.  On the NT4 it's accessible as


Well, it's usually a good idea to keep as many variables fixed as
possible.  By sharing the script, you've unknowingly introduced another
variable (that of SMB shares).  I'd suggest moving the script back to a
local directory, and simply copying it to the shared drive when you want
to try it on Linux.  That way you can reliably reproduce the problem on
the local drive.

And no, I've never heard of smbntsec. What's it mean/do?

See <>. It's on by default. FYI, it may require very careful hand-maintenance of /etc/passwd and /etc/group (in fact, I've ended up turning it off because the maintenance effort wasn't worth it for me). You might wish to add "nosmbntsec" to your CYGWIN variable. Igor

At 09:36 AM 8/26/2003, Rob Clack you wrote:


I've been away for a week, hence the delayed response.

Thanks for this and clearly my scriptlet was broken. I've now tried both alternatives as suggested below. Both work perfectly under Linux. Neither works under NT4.

Linux output:

script is executable

NT4 output:

I damn well am!

To eliminate error further, I'm now running just one copy of the script, since the disk I use on my Linux box is mapped to the i: drive on the NT4 box.

Are you suggesting that you're using a mapped drive from your Linux box? That may be the problem. Do you have 'smbntsec' set in your CYGWIN environment variable?

Unsubscribe info:
Problem reports:

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Middle age is when broadness of mind and narrowness of waist change places. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rob Clack Acedb Development, Informatics Group email: Wellcome Trust Sanger Institute Tel: +44 1223 494780 Wellcome Trust Genome Campus Fax: +44 1223 494919 Hinxton Cambridge CB10 1SA

-- Unsubscribe info: Problem reports: Documentation: FAQ:

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