I saved to disk using lynx, under ls it shows up but no matter what I have done back comes the statment no such file .
How do you erase these ls false readings or open what ls shows?
Show us the output from ls -l (in CODE tags).
Show us what you have done (in CODE tags) that produces the diagnostic message no such file ?
What ls false readings are you trying to erase?
Show us the exact, complete diagnostic (in CODE tags) that is produced when you try to open your file?
PS: What do you want to do to your file after you open it?
ls -l shows the names of the files, the false readings are the listed files that are not really there,
The purpose is reading these files they are txt file mostly(I would rather not give you any more data) it is nothing but using lynx within it using the download function , which says -save to disk, then using ls to check for the file , finding it listed then trying to open it to read be it with a txt editor or what ever and getting no such file as an , but what can code tags do?
Probably Lynx hasn't finished (properly) downloading. It should create a file in /tmp (AFAIK) before transfer to destination. Need to monitor download function.
sent from my HTC smartphone
We can't help if you won't help us see what is going wrong. We all know that ls -l shows the names of file AND a lot more; not just the names of files. SHOW us the ACTUAL output produced by the command: ls -l .
Telling us you are using a txt editor to open a file doesn't tell us what went wrong. SHOW us the ACTUAL diagnostic message(s) produced by your shell or by the text editor when it fails to open a file whose type, permissions, owner, group, size, timestamp, and name was displayed by ls -l .
Why would I give a complete stranger that kind of data?
So on it goes, sysiocod error #define ENOENT 2 /*No such file or directory */
Also it is a freebsd os not linux , shell t,
Prompt ~%
None of this is about programming only using unix to surf the web.
Also friend you sound liie a cop do you need my ip also, maybe my cc#,
You might give us that kind of information because you asked for our help diagnosing a problem and we need that information to help you diagnose that problem.
Now that we know you're using a BSD derived system, we know that the default ls output is likely to show certain control characters in filenames as sequences of other characters. I have never heard of a shell named t and I have no idea whether or not it contains a built-in ls utility that transforms names in some way.
Since some of the volunteers here know how some name transformations work, if we could actually see the exact diagnostic message produced by whatever utility is reporting " file not found " and the output from ls -l , we might be able to tell you how to open the file.
Maybe, if you're used to Windows instead of BSD, Linux, and UNIX Systems; you aren't aware that the files Abc and abc are two different files on those systems (even though either name would access a single file on many Windows systems).
Maybe there are <space>, <tab>, <carriage-return>, or <newline> characters in a filename. Multi-column ls output may completely hide that information; but ls -l output will in some cases make them that immediately obvious.
Maybe you have an alias installed for ls that is adding a character to the end of a filename to indicate the type of that file.
Maybe lots of other possibilities are affecting you. If you don't want to show us what is going on, that is your choice. I am not a cop. I do not want you IP address. I do not know what a cc# is, and do not want to know your cc#. All I want is information that will help us help you open your file(s). I do know that the standard ls utility on any BSD, Linux, or UNIX System will not show you the name of a file that does not exist.
1 Like
I believe the shell is what is considered the new c shell, tcsh, the problem is solved thank you very much for your efforts, I would rather not give you anything more it is a general problem that ls is showing a file name which is not there. I will be looking under I/o to learn to delete these , I have found you truly cannot open these listed files they were named but never constructed. As I wrote above it is a sysiocod error which means that there was a problem from the sender. Maybe lynx which is a text command line browser, or the web site . Thanks anyway , it is the standard ls utility on freebsd which shows blank names which are none constructed files being I think because they are to come from a third party and never do.
I'm glad that you have solved your problem.
But, ls does not show a filename that is not there. The filenames that ls does show may contain characters that disappear when displayed on a terminal, may contain characters that cause some characters of a filename to overwrite other text on your screen, and might contain sequences of characters that cause terminal to display some parts of a filename in random places on your screen (although I thought BSD versions of ls normally translated those sequences to visible character sequences). If you'd like help in removing these files (they really do exist), we'd be happy to help if you would supply some of the details we've requested. If you want to keep accumulating files that you don't seem to be able to process, that is your choice.
As Don has already said, you asked for assistance but then won't give us the information to allow us to answer correctly. What do you want? Wrong answers which we have had to guess?
If you have a Unix/Linux problem this is the right place to bring it. The experts volunteering their time are the best on the planet so please don't be so abrasive to us all.
Back to your problem, refer back to my post#4. I think you are right that the file(s) never arrive. During the download process, Lynx receives the data stream into a temporary file in /tmp and also holds a zero length file open in the destination directory that you specify. During the download process, those files are visible to 'ls' of course.
If the download process aborts, hits time-out, or whatever, Lynx will back-out and clean-up removing the files from /tmp and the destination directory. The result is that the file you saw using 'ls' is now gone!
This is a guess!!!