terminal does not recognize text files written with gedit or leafpad
- Inicie sesión o regístrese para enviar comentarios
After many years of using terminal to find and change files in linux,
today it became apparent that terminal does not even see some files,
in particular, files written and saved as text, i.e., file.txt, by
gedit or leafpad.
I saved these files in a particular folder, navigated to that folder
in terminal, and ... no such files. I even tried to sort the file in
terminal, e.g. "sort file.txt > filesorted.txt" but I got only a blank
file (filesorted.txt), so I had indeed navigated to the correct place
in the file hierarchy.
Then I opened file.txt with notepad and then saved it with a new name,
and then terminal sorted the newly renamed file OK and directed it to
filesorted.txt as originally intended, resulting in a file which opened
OK with leafpad. That file can also be opened with terminal.
I'm OK with the thought that terminal may be fussy about the kinds of
text file that it will process ... but not even _seeing_ such files
when they have been written in leafpad or gedit?
That looks like a bug to me.
However, the background is unusual. The text files started out as the
raw access files from my website, gz'd by cPanel,unzipped with Trisquel's
archive manager and then opened with leafpad, followed by importation
to a spreadsheet program called PSI-Plot (which I have been using for
about 25 years, first in DOS, then through several generations of the
Windows OS (where it always worked the same), and now installed from an
original program disk with Wine into by trisquel-operated Lenovo T420
laptop, where it still works the same. It can handle the huge raw access
files (seven columns by 300,000 rows) without difficulty.
In one such spreadsheet, I was extracting IP's and hostnames for addition
to the .htaccess file, and found myself facing a remaining column of
several hundred identities attempting entry into my nonexistent WordPress
client, and so I selected part of that column and copied it into a newly
opened leafpad file, about 10KB in size.
I have sorted sections of that .htaccess file with terminal before with
no problem, so there must be something about this unusual history of the
present leafpad text file which makes it invisible to terminal. The
.htaccess files entries are all made from or through the terminal, which
will accept text entries from just about any webpage where I can actually
read the text, even though LibreCalc's spreadsheet doesn't like it unless
I vet it first with terminal.
That's it in a nutshell.
George Langford
That is weird. Sorry to ask but are you sure you do not forget to save the file or save it somewhere else or start its name with a dot (if so, it is hidden)?
Since you write that the problem happens with different text editors saving the file (Leafpad or GEdit), I do not really believe in a bug. It would be a bug in a common library that would specifically aim to deal with files (a bug in 'ls' or in the terminal emulator looks even less probable)! Is the "file dialog", to select the file to save, the same in both applications?
What are the options you use to mount the filesystem where you save the file? The 'mount' command (without any argument) would tell. If you execute 'sync' before listing (with 'ls' I assume) the files in the directory where you saved the text file, does it appear? Does 'stat' see the file?
To actually receive help, it would be useful if you would copy-paste the simplest terminal session that demonstrates the bug. Something like:
$ leafpad path/to/file.txt # double-check that you actually save the file
$ ls path/to/
$ sync
$ ls path/to/
$ stat path/to/file.txt
Magic Banana inquired:
[Quote] That is weird. Sorry to ask but are you sure you do not forget to save the file or save it somewhere else or start its name with a dot (if so, it is hidden)?
Since you write that the problem happens with different text editors saving the file (Leafpad or GEdit), I do not really believe in a bug. It would be a bug in a common library that would specifically aim to deal with files (a bug in 'ls' or in the terminal emulator looks even less probable)! Is the "file dialog", to select the file to save, the same in both applications? [/Quote]
File was saved OK - My file manager had no difficulty listing it in the same directory where terminal couldn't see it.
As the original file was produced by a complex process sing a Windows app installed with Wine, I did the job over, this time using LibreOffice Calc to open the original text file as a spreadsheet ... which it did flawlessly in the blink of an eye ... and then sorted the spreadsheet for the search criterion (GET WordPress files) and for the searcher identities (IPv4 address or Hostname [Rant ahead: gratuitously converted by a misguided installation of cPanel on my shared server; most of those Hostnames could only be resolved to IPv4 addresses with considerable difficulty /Rant]) which it also performed in the blink of an eye.
Once sorted I separated the WordPress stuff - 600+ lines - and then used copy & paste to put the list into first, leafpad, and second, gedit, and then saved each file ... which terminal could find and open without complaint.
That points the finger of blame towards my strange juxtaposition of PSI-Plot and Wine. Last I heard, I was the only user worldwide of this combination, but I can't find any record whether I entered that information into Wine Headquarters, so I'll quietly steal away from that analysis.
Besides, LibreOffice Calc works much better, quicker, and more efficiently ... and can sort more than one column at a time in these huge (4+MB, 122,000 rows by a ten columns) data sets. PSI-Plot was taking forever to sort more than one column, so the present method using LibreOffice Calc actually eliminates the need for sorting the identities column to put the duplicates in bunches, making additional processing a lot easier. Just three days ... to get them into my .htaccess file.
So, by doing the job with the correct software, the bug must be considered thoroughly swatted.
BTW, the data I was looking at consists of apparently unorganized individuals and bots scattered all around the world, but about once a month, another group, probably using Russian servers that I can only indirectly identify by their use of a common open port, No.3389, the Windows Remote Desktop Port, so the whole shebang of servers, 22 in December 2017, 44 in january 2018, and 89 in February 2018, attempts to POST maliciously selected flawed WordPress Apps, Plugins, etc. into my nonexistent WordPress installation. That's documented here:
http://www.pinthetaleonthedonkey.com/StatisticsAllYears/POST-WordPress-Dec-19-Jan-09-Feb-15-2018-SortByDateTime.htm
Elsewhere in the analysis you will see that the Russians (maybe the same groups, but identified clearly) are perfecting the task of making their requests arrive nearly simultaneously by use of compromised intermediary domains and in great numbers, all controlled through that open Remote Desktop Port. They're targeting Windows/Mozilla/Internet Explorer weaknesses.
Thanks for thinking about this.
George Langford
My file manager had no difficulty listing it in the same directory where terminal couldn't see it.
Again: that is weird. Even if there is no simple way to trigger the bug, please show us at least a screenshot with your file manager displaying the content of the directory and a terminal session with 'sync' followed by 'ls /path/to/directory' (to substitute with the actual absolute path to the directory) not listing all the same files.
As the original file was produced by a complex process...
It should make no difference: the final program, which saves the file, does not even where the content comes from.
Magic Banana wondered:
[Quote] As the original file was produced by a complex process...
It should make no difference: the final program, which saves the file, does not even where the content comes from.[/Quote]
That's what has been bothering me. Text files are not supposed to harbour nasty scripts out of public view ...
Turns out that Magic Banana is correct: My "bug" has not reproduced itself. I couldn't find the original "terminally invisible" file, probably because I had modified it in my attempts to get it sorted, so I tried to repeat the whole process, starting with today's version of this month's Raw Access file, unzipping it, opening it with leafpad, importing the leafpad file into the Wine-installed PSI-Plot, selecting the WordPress-related GETs' and POSTs' requestor identities, and copying and pasting them into another instance of leafpad.
Whoops ! Terminal sees and sorts the newly created leafpad file just fine, thank you very much.
LibreOffice Calc still does a better job, as I can sort on two columns at once, eliminating the need to sort with terminal.
PSI-Plot's developer may have retired, but that program was and still is great for doing complex math & statistics problems and presenting the results in professionally publishable format ... except for JPEGs; first save the images in bitmap form and then compress them with GIMP. I use it now that I'm retired to re-publish surveyors' plats from their survey descriptions. They're all quite accurate, except that magnetic North isn't the same any more.
George Langford, wiping the egg off his face ...
LibreOffice Calc still does a better job, as I can sort on two columns at once, eliminating the need to sort with terminal.
The 'sort' command can do that (and much more): one or several --key (or simply -k) options can be used and --field-separator (or simply -t) specifies the character separating the fields (a space or a tab by default). See 'info sort' (notice that 'man sort' does not explain everything!). There even are well-explained at the end:
* Sort numerically on the second field and resolve ties by sorting
alphabetically on the third and fourth characters of field five.
Use `:' as the field delimiter.
sort -t : -k 2,2n -k 5.3,5.4
Note that if you had written `-k 2n' instead of `-k 2,2n' `sort'
would have used all characters beginning in the second field and
extending to the end of the line as the primary _numeric_ key.
For the large majority of applications, treating keys spanning
more than one field as numeric will not do what you expect.
Also note that the `n' modifier was applied to the field-end
specifier for the first key. It would have been equivalent to
specify `-k 2n,2' or `-k 2n,2n'. All modifiers except `b' apply
to the associated _field_, regardless of whether the modifier
character is attached to the field-start and/or the field-end part
of the key specifier.
* Sort the password file on the fifth field and ignore any leading
blanks. Sort lines with equal values in field five on the numeric
user ID in field three. Fields are separated by `:'.
sort -t : -k 5b,5 -k 3,3n /etc/passwd
sort -t : -n -k 5b,5 -k 3,3 /etc/passwd
sort -t : -b -k 5,5 -k 3,3n /etc/passwd
These three commands have equivalent effect. The first specifies
that the first key's start position ignores leading blanks and the
second key is sorted numerically. The other two commands rely on
global options being inherited by sort keys that lack modifiers.
The inheritance works in this case because `-k 5b,5b' and `-k
5b,5' are equivalent, as the location of a field-end lacking a `.C'
character position is not affected by whether initial blanks are
skipped.
- Inicie sesión o regístrese para enviar comentarios