|
Home > Archive > Unix Programming > December 2005 > "No such file or directory" in Batch mode
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
"No such file or directory" in Batch mode
|
|
| MajorSetback@excite.com 2005-12-29, 6:05 pm |
| I am using Red Hat Linux release 9 Kernel 2.4.20-8smp on an i686. I am
running csh.
I have C++ code that tries to open a file with the following call
----------------------------------------------------------------------------------------------------------------------------
if (!(fpInputFile=fopen(csFileName, "r"))) return
ErrorOpeningFile(csFileName);
long ErrorOpeningFile(char *csFileName)
{
fprintf(stderr, "Error opening %s\n", csFileName);
perror("Reason");
return ERROR_OPENING_FILE;
}
------------------------------------------------------------------------------------------------------------------------------
It works fine when I run the program at the command line. However,
when I run it in a batch file
$ csh BatchFile.csh
it fails and returns the message
Error opening /home/Peter/SubDir/File.nme
Reason: No such file or directory
I cannot understand the logic here since I give the full path name.
I have tried using a different directory and using double quotes around
the file file name but to no avail.
Any help would be greatly appreciated,
Peter.
| |
| Giovanni 2005-12-29, 6:05 pm |
| On 12/29/05 18:08, MajorSetback@excite.com wrote:
> I am using Red Hat Linux release 9 Kernel 2.4.20-8smp on an i686. I am
> running csh.
> [ cut ]
> It works fine when I run the program at the command line. However,
> when I run it in a batch file
>
> $ csh BatchFile.csh
>
> it fails and returns the message
>
> Error opening /home/Peter/SubDir/File.nme
> Reason: No such file or directory
>
> I cannot understand the logic here since I give the full path name.
>
> I have tried using a different directory and using double quotes around
> the file file name but to no avail.
>
> Any help would be greatly appreciated,
> Peter.
>
Either the file (or one of the component of the path) does not exists or
the user running the batch does not have r-x permissions on the
directories (or file).
Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
Registered Linux user #337974 <http://counter.li.org/>
| |
| Roger Leigh 2005-12-29, 6:05 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MajorSetback@excite.com writes:
> I am using Red Hat Linux release 9 Kernel 2.4.20-8smp on an i686. I
> am running csh.
Have you tried the same under sh/bash or any POSIX shell? AFAIK this
is a fairly ancient release. Have you considered upgrading? You
didn't mention which compiler version you were using, but if it's what
came with RH9, it won't be recent.
If you're doing software development, why use ancient and obsolete
tools when you could be using something decent, like GCC 4.0? This is
especially important if you're writing in C++.
> I have C++ code that tries to open a file with the following call
> if (!(fpInputFile=fopen(csFileName, "r"))) return
> ErrorOpeningFile(csFileName);
>
> long ErrorOpeningFile(char *csFileName)
> {
> fprintf(stderr, "Error opening %s\n", csFileName);
> perror("Reason");
>
> return ERROR_OPENING_FILE;
> }
Although it's not related to the problem at hand, just a few
criticisms:
1) Why does the function return a long? I can't believe you have that
many error codes! Why don't you
- return an int
- also, use enums rather than #defines, and return an enum rather
than some meaningless number. The compiler will then be able to
do static type checking of the return value.
- throw an exception derived from std::runtime_error. This could
also include an error code.
2) You are using Hungarian notation: fpInputFile? Urgh! Why not just
"fp" or "input"? It's type is obvious: a FILE*, so drop it from
the name, and use a name which is related to its use.
2) Why are you using cstdio and perror? C++ has iostreams, so why not
make use of them? std::cerr and std::clog exist just for this
purpose. If you really want format strings, try boost::format,
which gives you type safety, and works with std::ostream and
std::string rather well.
3) If you used iostreams, you can detect error using the builtin
methods, and if you must use a file descriptor or FILE * type,
__gnu_cxx::stdio_filebuf exists to wrap it in GNU libstdc++.
4) This isn't C++, it's C, and messy C at that.
This is the equivalent C++:
std::ifstream input(filename);
if (input)
{
// do stuff
}
else
{
throw error();
}
> It works fine when I run the program at the command line. However,
> when I run it in a batch file
>
> $ csh BatchFile.csh
>
> it fails and returns the message
>
> Error opening /home/Peter/SubDir/File.nme
> Reason: No such file or directory
>
> I cannot understand the logic here since I give the full path name.
Who knows? You didn't show us the script, so it's impossible to say.
Please read http://www.catb.org/~esr/faqs/smart-questions.html for
future reference.
> I have tried using a different directory and using double quotes around
> the file file name but to no avail.
Print out each item in argv so that you can compare the difference
between the two. It's probably a quoting issue. Try something like
this:
#include <iostream>
int
main (int argc,
char *argv[])
{
for (const char * const *iter = argv; *iter != 0; ++iter)
{
std::cerr << '"' << *iter << '"';
if (*(iter + 1) != 0)
std::cerr << ", ";
}
std::cerr << std::endl;
return 0;
}
With GNU Bash:
$ ./test hello world "test quoting" more\ testing 1 2 3
"./test", "hello", "world", "test quoting", "more testing", "1", "2", "3"
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
iD8DBQFDtCOuVcFcaSW/ uEgRAp+0AKDZr20cdlJ4kOZ6SiCZLDZcGM9PeACf
SG0e
2quj8Bvz4K2mgDEBzX25Kmg=
=FzZn
-----END PGP SIGNATURE-----
| |
| Bruce Barnett 2005-12-29, 6:05 pm |
| MajorSetback@excite.com writes:
> it fails and returns the message
>
> Error opening /home/Peter/SubDir/File.nme
> Reason: No such file or directory
the error you are getting (see errno(3)) is
ENOENT No such file or directory
The system call that gave you that error is
fopen(csFileName, "r")))
Checking the man pages - it says
ERRORS
EINVAL The mode provided to fopen, fdopen, or freopen was
invalid.
The fopen function may also fail and set errno for any of
the errors specified for the routine open(2).
going to open(2) it says
ENOENT A directory component in pathname does not exist or
is a dangling symbolic link.
so that's the problem.
--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.
| |
| Rich Teer 2005-12-29, 6:05 pm |
| On Thu, 29 Dec 2005, MajorSetback@excite.com wrote:
> I am using Red Hat Linux release 9 Kernel 2.4.20-8smp on an i686. I am
> running csh.
>
> I have C++ code that tries to open a file with the following call
>
> ----------------------------------------------------------------------------------------------------------------------------
>
> if (!(fpInputFile=fopen(csFileName, "r"))) return
> ErrorOpeningFile(csFileName);
Further to what Roger says: you're mixing Hungarian notation and csh;
no wonder you're having problems! I can't think of a more warped and
twisted mix... ;-)
> It works fine when I run the program at the command line. However,
> when I run it in a batch file
BTW, they're called shell scripts in UNIX.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
. * * . * .* .
. * . .*
President, * . . /\ ( . . *
Rite Online Inc. . . / .\ . * .
.*. / * \ . .
. /* o \ .
Voice: +1 (250) 979-1638 * '''||''' .
URL: http://www.rite-group.com/rich ******************
| |
| MajorSetback@excite.com 2005-12-29, 6:05 pm |
| Bonjorno Giovanni,
(I won't torture the Italian language any further.)
Many thanks for your reply. I figured out what the problem was. I had
accidentally inserted an (invisible) '\r' character in my shell script
file just after the filename. This appears to have been the result of
making the filename the last argument. When I made the last argument a
numeric value (by repositioning the arguments) the problem went away.
Grazie et ciao, (I lied ;-) )
Peter.
| |
| Kevin Collins 2005-12-29, 6:05 pm |
| In article <1135896788.426780.326390@g14g2000cwa.googlegroups.com>,
MajorSetback@excite.com wrote:
> Bonjorno Giovanni,
>
> (I won't torture the Italian language any further.)
>
> Many thanks for your reply. I figured out what the problem was. I had
> accidentally inserted an (invisible) '\r' character in my shell script
> file just after the filename. This appears to have been the result of
> making the filename the last argument. When I made the last argument a
> numeric value (by repositioning the arguments) the problem went away.
Please, PLEASE post some relevant text when you reply to a post. Otherwise,
many people have no idea what you are blathering about!
Kevin
--
Unix Guy Consulting, LLC
Unix and Linux Automation, Shell, PERL and CGI scripting
http://www.unix-guy.com
| |
| MajorSetback@excite.com 2005-12-29, 6:05 pm |
| Hi Roger,
Roger Leigh wrote:
> Have you tried the same under sh/bash or any POSIX shell? AFAIK this
> is a fairly ancient release. Have you considered upgrading? You
> didn't mention which compiler version you were using, but if it's what
> came with RH9, it won't be recent.
That would be something for my employer to decide. I will try to
mention it 'though.
>
> If you're doing software development, why use ancient and obsolete
> tools when you could be using something decent, like GCC 4.0? This is
> especially important if you're writing in C++.
I am using gcc-lib/i386-redhat-linux/3.2.2 . I figured out what my
problem was and outlined it in my reply to Giovanni.
>
> Although it's not related to the problem at hand, just a few
> criticisms:
>
> 1) Why does the function return a long? I can't believe you have that
> many error codes! Why don't you
> - return an int
When I started using C, an int could be 2 of 4 bytes. I guess a long
can be 4 bytes on Windows and 8 on Unix. 2 byte variables tend to give
me problems with alignment. (I develop code to run on Windows as well
as Unix/Linux.
> - also, use enums rather than #defines, and return an enum rather
> than some meaningless number. The compiler will then be able to
> do static type checking of the return value.
> - throw an exception derived from std::runtime_error. This could
> also include an error code.
Sometimes the errors are higher level and application specific. They
would not be defined by the compiler.
>
> 2) You are using Hungarian notation: fpInputFile? Urgh! Why not just
> "fp" or "input"? It's type is obvious: a FILE*, so drop it from
> the name, and use a name which is related to its use.
It seems that the subject of Hungarian notation makes politics and
religion seem fairly innocuous by comparison. I often find it quite
helpful when I am using something like gdb. It may not be quite as
useful for FILE*, but when I am using several layers of reference in
large code blocks, it becomes quite useful.
>
> 2) Why are you using cstdio and perror? C++ has iostreams, so why not
> make use of them? std::cerr and std::clog exist just for this
> purpose. If you really want format strings, try boost::format,
> which gives you type safety, and works with std::ostream and
> std::string rather well.
Seems like a more complicated way to do the same thing. What is wrong
with perror()
> Who knows? You didn't show us the script, so it's impossible to say.
> Please read http://www.catb.org/~esr/faqs/smart-questions.html for
> future reference.
Thanks.
>
>
> Print out each item in argv so that you can compare the difference
> between the two. It's probably a quoting issue. Try something like
> this:
>
> #include <iostream>
>
> int
> main (int argc,
> char *argv[])
> {
> for (const char * const *iter = argv; *iter != 0; ++iter)
> {
> std::cerr << '"' << *iter << '"';
> if (*(iter + 1) != 0)
> std::cerr << ", ";
> }
> std::cerr << std::endl;
>
> return 0;
> }
>
> With GNU Bash:
> $ ./test hello world "test quoting" more\ testing 1 2 3
> "./test", "hello", "world", "test quoting", "more testing", "1", "2", "3"
>
>
The problem was an invisible character. I doubt it would have shown up
in string outputs. I found it with od (octal dump).
Thanks,
Peter.
| |
| MajorSetback@excite.com 2005-12-29, 6:05 pm |
| Hi Bruce,
> ENOENT A directory component in pathname does not exist or
> is a dangling symbolic link.
>
>
> so that's the problem.
I have identified the problem and outlined it in my reply to Giovanni.
But what is the difference between a non-existent pathname and a
dangling symbolic link. I have done searches for the latter and, while
they usually don't say what it is, when it does it always appears to
say that it is the name of a non-existent file.
Thanks,
Peter.
| |
| MajorSetback@excite.com 2005-12-29, 6:05 pm |
| >
> BTW, they're called shell scripts in UNIX.
>
Pardon my French (or Windows).
Thanks,
Peter.
| |
| John Gordon 2005-12-29, 6:05 pm |
| In <1135897938.235029.27430@o13g2000cwo.googlegroups.com> MajorSetback@excite.com writes:
> But what is the difference between a non-existent pathname and a
> dangling symbolic link.
A dangling symbolic link exists, but points to a file which does not.
--
John Gordon "It's certainly uncontaminated by cheese."
gordon@panix.com
| |
| Keith Thompson 2005-12-29, 6:05 pm |
| Kevin Collins <spamtotrash@toomuchfiction.com> writes:
[...]
> Please, PLEASE post some relevant text when you reply to a post. Otherwise,
> many people have no idea what you are blathering about!
To do this using groups.google.com, read <http://cfaj.freeshell.org/google/>.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
| |
| Roger Leigh 2005-12-29, 8:52 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MajorSetback@excite.com writes:
>
> I am using gcc-lib/i386-redhat-linux/3.2.2 .
That's not too bad (it's not 2.95.x), but more recent compilers are
faster, generate tighter code, and are somewhat more standards
compliant (two-phase name lookup, better template support, support for
TR1, etc.).
>
> When I started using C, an int could be 2 of 4 bytes. I guess a long
> can be 4 bytes on Windows and 8 on Unix. 2 byte variables tend to give
> me problems with alignment. (I develop code to run on Windows as well
> as Unix/Linux.
Testing with this code:
#include <iostream>
int main()
{
std::cout << "short: " << sizeof(short)
<< "\nint: " << sizeof(int)
<< "\nlong: " << sizeof(long)
<< "\nlong long: " << sizeof(long long)
<< std::endl;
return 0;
}
$ ./sizes
short: 2
int: 4
long: 4
long long: 8
$ uname -srmo
Linux 2.6.14.5 ppc GNU/Linux
[glibc 2.3.5]
The results may well be different for other CPU architectures.
Alignment should not be an issue for returned errors though, unless
you are doing something dodgy like putting them in structures and
doing binary I/O. In this case, you should be using fixed sizes as
specified in <stdint.h>, such as int32_t, which are guaranteed to be
of the correct size.
>
> Sometimes the errors are higher level and application specific. They
> would not be defined by the compiler.
Sure, but they are defined by you, right? If you can't use an enum
for your application's error codes, then it's most likely there's
something wrong with the overall design that you might want to look
at. Static type checking is very useful, if you can do so.
As an example, check out
http://cvs.alioth.debian.org/cgi-bi...ot=buildd-tools
This is a simple exception class. You would use it like so:
class foo
{
enum error_code { ERROR_FOO, ERROR_BAR, ERROR_BAZ };
typedef Exception<error_code> error;
}
and then in any methods of this class, or in any derived class, you
can simply
throw error("description", ERROR_CODE);
This was actually written as a temporary measure when converting the
application from C to C++, and it does have some obvious drawbacks.
The current implementation is this:
http://cvs.alioth.debian.org/cgi-bi...ot=buildd-tools
If your application is written in C++, you might want to give some
thought to using exceptions where appropriate. Error propagation to
higher levels is an appropriate use.
>
> Seems like a more complicated way to do the same thing. What is wrong
> with perror()
It's extremely inflexible for all but the most trivial messages, and
you can't choose where to send the output. If you are writing
contemporary C++, it doesn't make much sense not to make use of the
native I/O facilities unless you have very special requirements.
Using streams also makes your output more flexible: you could log it,
and easily restructure your code to do different things. If perror is
sufficient, then by all means stick with it.
As an example, the application above does things like this:
log_error() << format(_("can't get supplementary group count: %1%"))
% strerror(errno)
<< endl;
This does logging to the stream returned by log_error, which could be
made configurable with no visible changes (this initial implementation
is deliberately simple, but future changes will be easy), and it
translates the message into the user's language with gettext.
This is a slightly better example, with a bigger format string:
log_error() << format(_("Could not exec \"%1%\": %2%"))
% arg_list[0] % strerror(errno)
<< endl;
(http://cvs.alioth.debian.org/cgi-bi...ot=buildd-tools
and
http://cvs.alioth.debian.org/cgi-bi...ot=buildd-tools)
Note that this is all GPL-licensed code.
[...][vbcol=seagreen]
>
> The problem was an invisible character. I doubt it would have shown up
> in string outputs. I found it with od (octal dump).
It would have shown spaces, due to the quotes, but not non-printable
characters.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
iD8DBQFDtIMDVcFcaSW/ uEgRAmZoAKCQc8RtoCnE04BCl2W5bqUsepfB2wCg
wa2H
3PSmqGAU94lFLk5tkQBM/9A=
=dQhx
-----END PGP SIGNATURE-----
| |
| Dan Espen 2005-12-29, 8:52 pm |
| MajorSetback@excite.com writes:
>
> The problem was an invisible character. I doubt it would have shown up
> in string outputs. I found it with od (octal dump).
Stay away from those Windows editors and you won't find /r in your files.
Emacs or XEmacs would have shown you the /r.
| |
| Bruce Barnett 2005-12-29, 8:52 pm |
| MajorSetback@excite.com writes:
> Hi Bruce,
>
>
> I have identified the problem and outlined it in my reply to Giovanni.
Yes, and it was useful. I posted my response so that he (and others)
can learn how to find the cause of ANY error message.
As Lao Tzu says, Give a man a fish, and you feed him for a day.
Teach him how to fish, and you have feed him for a lifetime.
--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.
| |
| MajorSetback@excite.com 2005-12-29, 8:52 pm |
| Dan Espen wrote:
> MajorSetback@excite.com writes:
>
> Stay away from those Windows editors and you won't find /r in your files.
>
> Emacs or XEmacs would have shown you the /r.
I was using vi. I guess that's an advantage of Emacs.
Thanks,
Peter.
| |
| Enrique Perez-Terron 2005-12-30, 3:00 am |
| On Fri, 30 Dec 2005 00:12:18 +0100, <MajorSetback@excite.com> wrote:
> Hi Bruce,
>
>
> I have identified the problem and outlined it in my reply to Giovanni.
> But what is the difference between a non-existent pathname and a
> dangling symbolic link. I have done searches for the latter and, while
> they usually don't say what it is, when it does it always appears to
> say that it is the name of a non-existent file.
A symbolic link is actually a small file containing a pathname.
If the link exists and contains a pathname to a non-existing file,
the kernel fails with ENOENT during lookup of the latter.
The user, upon seeing "No such file" does ls in the directory, and
gets confused by the existence of the pathname he specified. It is better
to include text about dangling links in the generic error message.
BTW, it does not have to be a directory component that is failing.
The last part of the pathname also generates ENOENT.
-Enrique
| |
| Kenny McCormack 2005-12-30, 5:55 pm |
| In article <Pine.SOL.4.64.0512291423070.1991@marrakesh>,
Rich Teer <rich.teer@rite-group.com> wrote:
>On Thu, 29 Dec 2005, MajorSetback@excite.com wrote:
>
>
>Further to what Roger says: you're mixing Hungarian notation and csh;
>no wonder you're having problems! I can't think of a more warped and
>twisted mix... ;-)
>
>
>BTW, they're called shell scripts in UNIX.
I think that's the whole point - that he thinks of it as a batch file,
which implies that he probably wrote it on Windows, using a Windows/DOS
editor. Hence the problem.
This thread has been an interesting read, though - talk about going far
a field in search of an answer that was so obvious. Once he said "batch
file", the solution should have been obvious.
BTW, it has become pretty much standard knowledge in these Unix oriented
newsgroups, that whenever something unexplainable happens (like "the file
is there, but the program can't open it"), that Windows is somehow
involved.
|
|
|
|
|