On 6/9/21 2:55 AM, Richard Kettlewell wrote:
> That’s not how shell quoting or find -exec work.

Please elaborate.

> The real problem with these commands is that they contain a well-known
> vulnerability. For details see:

I completely agree that there is a timing component (race condition)
that can be a problem. But that's not the component I was speaking to.

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 6/9/21 2:55 AM, Richard Kettlewell wrote:
>> That’s not how shell quoting or find -exec work.
>
> Please elaborate.

I have too much RSI to repeat shell-quoting rules and the semantics of
find -exec. You will have to look them up.

--
https://www.greenend.org.uk/rjk/

In alt.os.linux.slackware, Richard Kettlewell <invalid@invalid.invalid> wrote:
> Grant Taylor <gtaylor@tnetconsulting.net> writes:
>> Drive by comment: Be careful with filenames with spaces in them. I'd
>> suggest putting double quotes around the {} in the find -exec
>> statements.
> That's not how shell quoting or find -exec work.

Agreed. Note that I'm using ksh and have PS2 set to <TAB> here:

$ cd /var/tmp
$ mkdir 'I
U+2665
trouble' && cd I*trouble
$ mkdir '`echo nana`'
$ touch '`echo nana`'/'
yikes
'
$ cd ..
$ find . -size 0 -type f -exec ls -ld {} +
-rw-rw-r-- 1 username username 0 Jun 9 11:35 './I'$'\n''U+2665'$'\n''trouble/`echo nana`/'$'\n''yikes'$'\n'
$

Since I'm using ksh, {} is not special to shell, and does not need
quoting. Since {} is safely replaced by find, whitespace and shell
metas in names is not an issue.

Elijah
------
did not actually include the unicode, just the U+codepoint

On Tue, 08 Jun 2021 23:06:09 +0000, Lew Pitcher wrote:

> On Tue, 08 Jun 2021 16:37:35 -0600, Grant Taylor wrote:
>
>> On 6/7/21 1:57 PM, Henrik Carlqvist wrote:
>>> -8<---------------------------------
>>> #!/bin/sh
>>> # Cleanup /tmp however, do not remove sockets for X
>>>
>>> # No lost+found with reiserfs, but ext* has it...
>>> find /tmp/lost+found -exec /bin/touch {} \;
>>> find /tmp -type s -exec /bin/touch {} \;
>>> find /tmp -type d -empty -mtime +37 -exec /bin/rmdir {} \;
>>> find /tmp -atime +37 -exec /bin/rm {} \;
>>> -8<---------------------------------

> For added security, I would rephrase the command to:
> find /tmp -atime +37 -print -delete
> to keep a record of files and directories deleted.

Thanks for all comments!

I will try:

find /tmp/lost+found -exec /bin/touch {} \;
find /tmp -type s -exec /bin/touch {} \;
find /tmp -type d -empty -mtime +37 -print -delete
find /tmp -atime +37 -print -delete

The record of deleted files will end up in emails to me. As this cron job
is being run on 50+ machines it will probably mean 50+ emails every
night. I might remove the -print if it gets too much to read...

regards Henrik

On 6/9/21 2:52 PM, Henrik Carlqvist wrote:
> The record of deleted files will end up in emails to me. As this cron
> job is being run on 50+ machines it will probably mean 50+ emails
> every night. I might remove the -print if it gets too much to read...

(Pro)Tip: Have one string of text for success and another string of
text for failure. Then configure email client filtering to mark success
messages as read (and file them away). That way you can easily look at
the folder and see that the cron job is running like it should be. If
there ever is a failure, it will remain unread (maybe filed away, maybe
not) so that it will garner your attention to investigate the failure.

I've learned that it's really difficult to tell from afar if a
completely silent script is always succeeding or simply not running. I
dislike that.

--
Grant. . . .
unix || die

On Wed, 09 Jun 2021 18:19:37 -0600, Grant Taylor wrote:
> I've learned that it's really difficult to tell from afar if a
> completely silent script is always succeeding or simply not running. I
> dislike that.

Thanks, yes, I share that experience. During the years it has happened
that the crond daemon has died completely. Fortunately all those machines
are also monitored by software which will tell if some important deamon
has died and/or if some partition is getting more than 90% full. I have
/tmp on a separate partition.

regards Henrik