Linux Find and/or Locate Files/Directories Application Extensions Tutorial
A lot of us have FOMO … ie. Fear of Missing Out … over something. One that worries us, running a web server, is the fear of missing out on the daily report we get regarding software on the RJM Programming website telling us …
What, we term as “Application Executable” files, changed on the RJM Programming web server within the last 5 days
Today’s nuanced change to our arrangements revolve around the file extension list covering “Application Executable” files. We’d been covering …
- *.htm*
- *.html*
- *.php* … but not, until today …
- *.*htm*
Yes, read about the *.phtml extension, and we’ve seen with error handling *.shtml and *.dhtml as well. So, yes, we’re definitely interested!
We’re hoping today’s tweaked and changed Korn Shell script called todays_list.ksh called (regarding the report creation only) via crontab …
mm hh * * * ksh /etc/init.d/todays_list.ksh
… (mm represents minute of hour of day and hh represents hour of day) can ease the “FOMO within”, further to the previous Linux Find and/or Locate Files/Directories Double Quote Tutorial.
Previous relevant Linux Find and/or Locate Files/Directories Double Quote Tutorial is shown below.
Linux Find and/or Locate Files/Directories Double Quote Tutorial
When you write inhouse procedures that end in reports you can occasionally “get sideswiped” by peculiarities in the data that occurs. But it could be the cause of that irregularity that the report is meant to highlight. And so, if there is a problem showing the report, then what’s the point?!
This started happening to us the other day with the procedure that sends us information about “files changed in the last week” on this RJM Programming domain, whose blog you are reading now. This report gives a list of Linux web server files changed since the last week, roughly. We first talked about all this way back with Linux Find and/or Locate Files/Directories Primer Tutorial.
Our research started because of an error message when bringing up the “files since” report …
Parse error: syntax error, unexpected ‘Z’ (T_STRING), expecting ‘,’ or ‘;’ in todaylist.php on line 155
… making us think this was a PHP coding issue. Please don’t jump to conclusions though. Anyway, step 1 should be to go to “todaylist.php” (the “files since” report, we needed to be reminded) to its line 155. Doh?!?! Got us to see the record …
<br>./PHP/x_f(now)=sysdate().sleep(3),0))XOR”Z.htm
Huh?! Yes, you are not alone aghast about this form of filename! But it’s possible, so there are now two problem aspects …
- the immediate problem (of those files existing) … the date being old told us that this was caused by a one off coding issue on a day … so we deleted files of this ./PHP/x_*.* filespec … there were a few … but also …
- the long term issue … our reporting coding should be able to handle this, so as to proceed with the report, and hence lead us to the issue on an immediate basis, on which the rest of this tutorial concentrates
Okay, then, we first did this. We rewrote the todaylist.php content without problematic filenames into a tlist.php incarnation until we got a clear run. The various line numbers encountered showed us the problematic filename characteristic in common with the problems was the existence of …
”
… we’ve always wanted to do this … character within filenames. This aligns with a common PHP issue. Having double quotes un-backslashed within data delimited by double quotes is bound to cause issues. This made us follow the path of making the data contain backslashed double quotes, should they occur within file names.
This filename data, we discovered, and were reminded about (though you can read below … doh!?!?) gets created via a crontab Korn Shell procedure we have now changed to be todays_list.ksh where a piped sed clause helps create this backslashed double quote scenario to occur at the filename data creation stage of the procedures, leaving any PHP involved not needing to change, as you can see with today’s tutorial animated GIF presentation. Aaaaaaaahh!
Previous relevant Linux Find and/or Locate Files/Directories Primer Tutorial is shown below.
Linux Find and/or Locate Files/Directories Primer Tutorial
Linux (or Unix) servers have two really useful commands which help the user find files and/or directories … locate and find. Doubt there are many people out there who have not mislaid a computer file at some time or other. The GUI options are there, such as Windows Explorer and Mac Finder, but you tend to think, with these, of the one area or folder to search (mind you both are capable of better), whereas you often face the dilemma of having no idea where the file is. The GUIs can help here, but find, for myself, that I always jump to the command line for this, with Windows command line DIR C: [filespec] /s or the Linux/Unix commands for today’s tutorial … locate and find.
So why confuse things with two choices? Well, locate is fast, once set up, because it sets up its own “database” of previous knowledge, and so can pluck out whatever you want really fast from then on, once you use a “sudo” command to set up locate for future use.
The strength of the Linux/Unix find command are its switches like “-type ?” to define what type of file to find, and the way you can use “exec” in a piped scenario, to add more functionality.
So some words about the syntax (and for this, found Linux by Steve Oualline and Eric Foster-Johnson (pp 72-73) an excellent source) where you can hover or click for further information:
- locate gimp | more -y 13
- find / -name “*gimp*” -type f -print 2> /dev/null | more -y 13
- find $HOME/Documents -name “*.htm*” -type f -exec fgrep body {} /dev/null ;
So today we see some actions to find and/or locate files/directories with this tutorial.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
