hi, On Wednesday, 21 September 2022 at 01:40:05 UTC+1, Greg Wooledge wrote: > On Tue, Sep 20, 2022 at 10:19:50PM +0100, jr wrote: > > On Tuesday, 20 September 2022 at 12:30:05 UTC+1, Greg Wooledge wrote: > > > ... > > > With this new information, it occurs to me that perhaps the OP did > > > something like this: ... > > > unicorn:/tmp/x$ find . | tar cv --files-from=- -f ../foo.tar > > > > I prefer 'locate' to 'find'. an no guessing involved, as I wrote on > > the 18th, the invocation was: > > $ tar -cvWf $arcname $fnames > > > > where $fnames initially was a list in a variable (this is preparing a > > shell script), then I switched to storing in those in a file and > > $ tar -cvWf $arcname $(cat $fname_list_file) > So... what's in these variables? What's in the file pointed to by > the last variable?
"what's in these variables?" $arcname := name of archive, eg '/tmp/220921_bkup.tar'. $fname_list_file := the name of a file much like the previous. "What's in the file" file names, one per line. (and, before you ask, '\n' terminated lines) > In general, your approach of "storing a list in a string variable using > spaces and word splitting" is utterly crap and will NOT work with > arbitrary filenames. Filenames can contain spaces and globbing > characters. fwiw, in my personal space(s) I have long since learned the value of .. good hygiene, and neither space characters nor wildcards "allowed". that leaves files with "exotic" names (some utf8); I have none at present but am aware that there are mount options that would help in such a situation. "your approach ... is utterly crap" charming. </shrug> (and yet, in spite of your .. low opinion, I do get by ;-)) > But that's probably not the main issue -- unless one of your filenames > happens to contain an asterisk or two. if a mis-typed command line should lead to such a name being created, the file would be renamed, or removed, soonest. > It's just as likely that your "list" has duplicates in it. (reading comprehension, we ought to talk that topic sometime :-)) as I wrote, I use 'locate'. that is database-backed[*], and, afaik, there are no "issues" with this (mature) software. [*] the advantage of using a database -- if done properly, there's no duplication of _anything_. btw, I find 'locate' also makes all sorts of ad-hoc stuff easy. one of the s/wares I use uses .inc files, so if I wanted to have a quick look, I could (from any working directory) simply: $ less $(locate thing.inc) and yes, it does require some knowledge of one's system and files, the naming, etc, but you'll need that anyway. > If you'd show the content of those variables (and the file) maybe we > would know. typically I'd use a pipeline of commands. a 'locate', followed by a 'grep -v' with one or more expressions to filter out unwanted, followed, depending on use, perhaps by a 'tr' if I don't need/want newlines. I may also get rid of a common prefix with an 'sed'. example (typed, not copy/paste): $ locate /jr/ | > grep -v -e /.cache/ -e /tmp/ | > sed -e 's#/home/jr/##' would give me a "nice" clean list of relative file names, to use in some way, for instance to pass to tar. and lastly, just because I find it .. interesting, meant to say that one can get a good impression of an online stranger, in a situation like this, when one looks at what gets snipped, and when, and or gets passed over. my impression now is that you're the type of person who wears a MAGA baseball cap at the dinner table, am I close? :-)
