removing selected files
 

Hello all,

I should like to know if there's a purely Bash solution to
this scripting problem (I know how to solve it using an OCaml-created
executable, but that's heavy somehow...)


Given a directory, erase the PDF files in it coming from a TEX or LATEX file
(in other words, erase only the files whose names ends in .pdf,
and erase xyz.pdf only when xyz.tex exists in the directory).

Ewan

Not fully tested and will probably break if your file names have spaces.

// Tony

This works, except that
should be
and
should be By the way, to include the treatement of filenames ending with an uppercase PDF,
with what should I replace "for i in *.PDF" ?
Does "for i in *.pdf *.PDF" work ?

Ewan

Actually Ewan, it should be 'basename -s pdf' - I forgot that line when I was translating from another script.

I also got the test wrong - it should be [ -a $dname ]

Covering both PDF and pdf is harder - this should do it.

Not enough time to test totally but it does appear to work. Once again, spaces in filenames will ruin it.

// Tony

No... -a is used as an "and" to join 2 *tests* together -- so -a with one only arg is almost meaningless (perhaps equivalent to -e?).
The -f you had before was just fine.


Wrong again. First, either .pdf or .PDF alone is enough to get the shell to match all cases. (Try it... the filename behavior in OSX is case insensitive: ls ~/*EsKtOp will list Desktop items). Second, having both .pdf and .PDF as args to the for statement actually creates a problem... because it matches everything twice, and so the script ends up trying to do more than necessary. [e.g., when run with echo or ls it prints every match twice.]


Missing the trailing backtick` there. (seems to me, both your scripts were *fully* untested).


Don't need the quotes there. dname=${base}doc will do just fine. [doc?]

The trick is to quote the "$dname" variable when it gets used. Note: the dname variable from your first post (after if [ -f) was missing the $ prefix to make it a variable. So if [ -f dname ] would always fail (unless some file named "dname" was present).

All that's needed is quotes in the proper place.

--

If case doesn't matter (i.e., only lowercase .pdf files will exist), then this is good enough:

x=.pdf y=.tex; for i in *$x; do [[ -f `basename -s $x "$i"`$y ]] && ls "$i"; done
[i used the x and y variables to make the script more easily adaptable.]


If both .pdf and .PDF items need handling, then more syntax is required:

xa=.pdf xb=.PDF y=.tex; for i in *$xa; do
[[ -f `basename -s $xa "$i"`$y ||
-f `basename -s $xb "$i"`$y ]] && ls "$i"; done

Note: oddball 'mixed-case' instances (like .Pdf) will go undetected.

Naturally, change the ls command to rm once you're satisfied it works. I'm fairly certain it won't trip over any spaces in filenames. But, i didn't test for all potential filename gotchas (such as quotes, slashes and various other hazardous punctuation).

-HI-

No, I tested it quickly. It was a conversion from a script I used for something similar and the cut and paste wasn't perfect - my version has the closing backtick.

I was actually thinking after I posted that I had it backwards - if the case of the .tex files is always correct then the smart way would be to loop through those and then just change the rm to 'rm "${base}[Pp][Dd][Ff]"' and cover all the cases.

There is s good case for basename -s having a case insensitive option <g>.

// Tony

Fortunately, the case of the .tex files is of no consequence... as once again, the shell is making that call (or rather the OS is i guess):
Your rm "${base}[Pp][Dd][Ff]" idea is great. I like that.

[Though, hopefully that extreme is never needed... i prefer the flexibility of those x and y variables, for simple script alteration. Then again, if it's always gonna be pdf files... sure, why not.]


Agreed! :)

Actually, it seems your solution is not working Hal : when I tried it on my
files, I got error messages indicating that the basename command was used
with an incorrect syntax (although I can't figure out why).

Is there a special reason you use a && instead of a "if" construct (which
seemed more natural to me in this case?)

Ewan

The following code loops through each .tex file and removes the corresponding .pdf file if it exists:

(EDIT: only works with .tex and .pdf -- i.e. not .PdF .Tex etc)
(EDIT 2: updated code at end)

In fact, you can remove the 2nd and 4th lines and it'll still have the desired effect. The only difference being that you'll get a "rm: <FILE_NAME>.pdf: No such file or directory" warning for each .tex file that doesn't have a corresponding .pdf.


EDIT 2: the following code works for *.TeX, *.PDf, etc:

NOTE: the deletion works because rm <FILE_NAME>.pdf will remove <FILE_NAME>.pDf and so on. But this only works when .pdf is outside the quotes. Similarly for the file test.

Show me (copy/paste) the entire Terminal session, *including* the command used (and perhaps a listing of the working directory too).
BTW, what Mac OS and Bash versions are you running?


For a simple if/then (single stage), i much prefer the list construct. That's what feels "natural" to me. When things get deeper (nested if/thens), then i revert to what is easier.

I, OTOH, started out life as a C programmer (you should see my Python code - I frequently forget and loop over something rather than use a map function) so I prefer if/thens. :D

// Tony

Apologies Hal, your solution did work but a character slipped in my copy/paste
and I didn't notice ...

The use of "%" in FingerEater's solution is terser and better (I think) than invoking
the basename command. I had never read about this use of "%" in Bash before. Is there
a site where it is explained in more detail (not the Bash manual ...) ?

For the record, below is the script I finally wrote to get rid of some files produced
by pdflatex, not only in the current directory but also in any subdirectory :

Try pasting this url in Safari and see if you have this file:
file:///usr/share/doc/bash/bashref.html#SEC30

Else, google for "Shell Parameter Expansion".

That does work. But (as i mentioned above in post #5) this will also match *all* cases:

for i in *.tex


I'm not getting any warnings here.
From what i can see, this works perfectly (even with weird 'mixed-case' files):

for i in *.tex; do ls "${i%.*}".[Pp][Dd][Ff]; done

Does that **not** work for someone? (Show me listing and session).

Gotta admit, i considered a shell parameter expansion solution at first... but i was unable to put it together so cleverly, the way you did. Ironically, roparzhhemon likes it (and so do i) because it's "terser and better". So... what happened to "natural" then? :D

I suppose you know this already, but i'll say it anyway:
while that script does find tex files everywhere in the hierarchy...
the only pdf, aux, log, and dvi files it's looking at (for comparison purposes)
are in the top level of the current working directory.

On my system (OS X 10.5.8, Bash 3.2), I get:

However, "rm 4.pdf" will delete the file "4.PDF".


I get the following:

So *.tex is not matching 3.TEx, 4.b.teX, 5 and a half.teX, or 6.TEX.


But, (a modified version of) the code I gave produces:

and a further edited version produces:

Ah, i see my mistake now (no extra tex file, duh)... thanks.
You were right.

I'm liking this now:

for i in *.tex; do [ -f "${i%.[Tt][Ee][Xx]}".pdf ] && ls "${i%.*}".[Pp][Dd][Ff]; done

Strictly speaking, the final [Pp][Dd][Ff] isn't needed (pdf will do).
But, it's nice to see it list the file using the exact case of the file.

That still doesn't work. You need to replace i in *.tex with i in *.[Tt][Ee][Xx]. And then ${i%.[Tt][Ee][Xx]} can be replaced by ${i%.*}. Using the same set of files as in my previous post:

EDIT: As pointed out below, the first bit should in fact read:

Works just fine here (using *your* recent file list).
Is your disk formatted as a case-sensitive filesystem perhaps?
Very few people do that.


As already discussed, that's not needed (see post #5):
Makes absolutely zero difference (but adds 9 unnecessary chars).
If your Mac can't reproduce that output, then your filesystem must be case sensitive.


Whoa, what is that stuff in red? I never posted that.

I get a different output in the second case. Only 1.tex and 2.tex are printed. In fact, just doing "ls *.tex" only outputs 1.tex and 2.tex. My machine (a G4 PowerBook, circa March 2004) was originally a Panther system and was upgraded to Leopard via an "Archive & Install". I've never reformatted my HD at all, so it's not something I have done willingly (I don't recall being given that option when upgrading to Leopard). I can't seem to find the info in Disk Utility or System Profiler - do you know where it would be shown? (EDIT: found it, see below) Of course, it would appear that my file-system is indeed case sensitive.

Oops, sorry. Looks like I copied and pasted the wrong thing in my history. However, what you posted gives the same output as was indicated (on my seemingly case-sensitive system). I've updated my previous post accordingly.


EDIT: Output from diskutil in Terminal

Oddly, there is no mention of "case-sensitive" in the file-system type... (this post says there should be)

EDIT: Upon further reading, the bash shell seems to be case-sensitive, but can be told to be case-insensitive. Hal, you don't happen to have the 'nocaseglob' option set, do you? (e.g. in your .bashrc or .bashprofile files)

If I set that option, I get the output you get:

Hmm, you know what? At this point, an extra 9 chars which make a script work for both case-sensitive and case-insensitive filesystems? Fine, it's worth it. Let's not discuss it any further.

:) [kidding]

Yeah, it's not an option. We have to plan and prepare for it ourselves (backup everything and -- when booted from the system DVD -- use the Disk Utility there to erase the HD, just before installing the new OS). Only those folks who want to go through all that procedure even bother. I like to do it for major system upgrades, e.g., Tiger to Leopard. I figure the Disk Utility in 10.5.0 knows what's best for OS 10.5.0 -- better than Disk Utility in Tiger or (egads) Panther anyway. A clean install on a virgin disk. Ahh, no worries.

--

Do you use Adobe Products? (Creative Suite, etc.)
I've read they bug-out on case sensitive filesystems.
Then again, it's not 100% clear that's what you have.
[Maybe start a new thread for this... i'm not sure.]

Nope, no Adobe software.

Did you see my (many) edits in the last post? I definitely don't have a case-sensitive system, but passing the 'nocaseglob' option to bash gets me the behaviour you have (i.e. bash is case-sensitive by default). Looks like 'nocaseglob' could be key...

Guilty...

<sigh> i hate unix. :D

--

You're right, this one's more universal:

for i in *.[Tt][Ee][Xx]; do [ -f "${i%.*}".pdf ] && ls "${i%.*}".[Pp][Dd][Ff]; done

[now i have to find that thread at ars technica where i got mislead last spring... it's probably locked. ;-) ]

Hey, at least the tangent which we took this thread on has come to a (satisfying?) end. You had me worried about my system for a while there...! :p

It's like the universe: probably makes a lot of sense if you know all the rules governing it! (Unfortunately, no one does...)

If you're going to do that, you might as well also do:

(and why do I think you probably already have?).

The trick is to remember that you've done it.
Unix ought to have a "list all my customizations" command. Hmm... that shouldn't be too hard. Write a script to capture all settable options to a file:

alias -p
bind -pvs
enable -p
shopt -p
set

Generate the same file from a virgin install, and keep it around. (Such a file could be part of a virgin install. Or log in as Guest and run the script.)
Use diff to find all the ways you're different.
You'd probably also want to have a list of ignorable differences (like the value of $USER or $HOME).

No... I will resist. (Another reason to hate unix -- it sucks you in by making everything seem so doable.)

Yes, but for some reason i have...
bind 'set completion-ignore-case on'

Not sure if that trailing "on" is redundant or what. [?]
Can't remember where i dug that up. [i'd like to find a good tutorial on bind.]


Now he tells me. :o

From info readline (which oddly is more complete under Tiger than Leopard, probably because manually installing ruby gave me a later version),

I'm glad you're back from vacation. Things have been dull without you.