[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: not wanting to delete somebody's home directory



On Fri 05 Jul 2019 at 18:39:51 (+0100), mick crane wrote:
> On 2019-07-05 17:31, songbird wrote:
> > mick crane wrote:
> > > hello,
> > > I doing some code in perl and I'm not very good at it.
> > > code makes some images and saves them to a directory.
> > > If the directory doesn't exist it gets made and if it does
> > > exist all the
> > > files in it get deleted before putting some new ones in.

Just don't ever do that.

> > > I'm thinking that if I ever give it to somebody it's possible
> > > they might
> > > call the directory
> > > "~/" or something and end up deleting all their files, which
> > > I'd like to
> > > avoid.
> > > How would that best be avoided ?
> > > Is that something to do with chroot which I don't know anything about.
> > 
> >   always put things in a subdirectory.
> > 
> >   there is normally a directory named .local/share/<program-name>/
> > used for such things (or create it if it isn't there).
> > 
> >   if you have any configuration information that can be saved in
> > the .config/<program-name>/ directory (or again create it if it
> > isn't there).

Alternatively, use a Perl function to create a temporary directory for
you in your choice of location. It will avoid any name collision, and
as the program finishes, it can attempt to rename it to your choice at
the end of the run. If it fails for whatever reason (collision, say),
then it can print the name it used, and leave you to rename it
yourself (using   mv -i   for safety).

It's always worth taking full advantage of a language's libraries
because they will have ironed out all the wrinkles. And leave any
file removals for the user involved to do. Then they can only
blame themselves.

> I'm incrementing the number by the loop and some software sees 2 as
> bigger that 10 or something like this. I can probably get around that
> by adding to a very large number in the loop and calling them that.

Similarly, you can create temporary files in your new directory, and
build a list of their random names in a list variable. At the end of
the program run, it will know how many files there are, can choose
the number-length accordingly, and rename them in the correct order
using its list.

> I don't mind deleting them by hand but if I have to run program
> several times to tweak what images look like it slows things down.

If you construct a prefix for your directories like YYYYmmddHHMMSS,
they will have the advantage of collating in the order they were
created, when running the program however many times.

I no longer use Perl (in favour of Python) so I'm not familiar with
the names of the library functions, but the documentation for the
equivalent Python functions shows what you're trying to achieve:

    tempfile.mkdtemp(suffix=None, prefix=None, dir=None)

    Creates a temporary directory in the most secure manner
    possible. There are no race conditions in the directory’s
    creation. […]
    The user of mkdtemp() is responsible for deleting the temporary
    directory and its contents when done with it. [You would
    of course rename it.]

    tempfile.mkstemp(suffix=None, prefix=None, dir=None, text=False)

    Creates a temporary file in the most secure manner possible. There
    are no race conditions in the file’s creation, […]
    […] the user of mkstemp() is responsible for deleting the
    temporary file when done with it. [You would of course rename it.]

    If suffix is not None, the file name will end with that suffix,
    otherwise there will be no suffix. […]
    If prefix is not None, the file name will begin with that prefix;
    otherwise, a default prefix is used. […]
    If dir is not None, the file will be created in that directory;
    otherwise, a default directory is used. […]

      Extracted from a version of https://docs.python.org/2/library/tempfile.html
      You will probably be more interested in a Perl page like
      https://perldoc.perl.org/File/Temp.html

Now you can concentrate on the job at hand, without having to consider
file and directory creation at all.

Cheers,
David.


Reply to: