Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #210782 > unrolled thread

not wanting to delete somebody's home directory

Back to article view | Back to linux.debian.user

Contents

  not wanting to delete somebody's home directory mick crane <mick.crane@gmail.com> - 2019-07-05 17:30 +0200
    Re: not wanting to delete somebody's home directory Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-05 17:30 +0200
      Re: not wanting to delete somebody's home directory mick crane <mick.crane@gmail.com> - 2019-07-05 17:40 +0200
        Re: not wanting to delete somebody's home directory The Wanderer <wanderer@fastmail.fm> - 2019-07-05 17:40 +0200
          Re: not wanting to delete somebody's home directory Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-05 17:50 +0200
            Re: not wanting to delete somebody's home directory The Wanderer <wanderer@fastmail.fm> - 2019-07-05 18:20 +0200
              Re: not wanting to delete somebody's home directory Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-05 19:00 +0200
                Re: not wanting to delete somebody's home directory The Wanderer <wanderer@fastmail.fm> - 2019-07-05 19:30 +0200
        Re: not wanting to delete somebody's home directory mick crane <mick.crane@gmail.com> - 2019-07-05 17:40 +0200
    Re: not wanting to delete somebody's home directory songbird <songbird@anthive.com> - 2019-07-05 18:40 +0200
      Re: not wanting to delete somebody's home directory john doe <johndoe65534@mail.com> - 2019-07-05 19:40 +0200
        Re: not wanting to delete somebody's home directory Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-05 20:00 +0200
      Re: not wanting to delete somebody's home directory mick crane <mick.crane@gmail.com> - 2019-07-05 19:50 +0200
        Re: not wanting to delete somebody's home directory David Wright <deblis@lionunicorn.co.uk> - 2019-07-05 21:10 +0200
          Re: not wanting to delete somebody's home directory mick crane <mick.crane@gmail.com> - 2019-07-05 23:00 +0200
        Re: not wanting to delete somebody's home directory Curt <curty@free.fr> - 2019-07-06 10:40 +0200
          Re: not wanting to delete somebody's home directory songbird <songbird@anthive.com> - 2019-07-06 13:10 +0200
            Re: not wanting to delete somebody's home directory Curt <curty@free.fr> - 2019-07-06 14:40 +0200
              Re: not wanting to delete somebody's home directory Wolf Halton <wolf.halton@gmail.com> - 2019-07-06 15:10 +0200
              Re: not wanting to delete somebody's home directory rhkramer@gmail.com - 2019-07-06 16:30 +0200
                Re: not wanting to delete somebody's home directory "Thomas Schmitt" <scdbackup@gmx.net> - 2019-07-06 17:40 +0200
                  Re: not wanting to delete somebody's home directory "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2019-07-06 18:10 +0200
              Re: not wanting to delete somebody's home directory David Wright <deblis@lionunicorn.co.uk> - 2019-07-06 17:20 +0200
      Re: not wanting to delete somebody's home directory mick crane <mick.crane@gmail.com> - 2019-07-05 20:00 +0200
        Re: not wanting to delete somebody's home directory mick crane <mick.crane@gmail.com> - 2019-07-05 21:10 +0200
    Re: not wanting to delete somebody's home directory David Christensen <dpchrist@holgerdanske.com> - 2019-07-05 22:30 +0200

Page 1 of 2  [1] 2  Next page →

#210782 — not wanting to delete somebody's home directory

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.
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.

mick

-- 
Key ID    4BFEBB31

[toc] | [next] | [standalone]

#210783

On Fri, Jul 05, 2019 at 04:24:42PM +0100, mick crane wrote:
> 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.

Have you considered simply *not* deleting all the existing files?  Just
leaving them alone?

[toc] | [prev] | [next] | [standalone]

#210785

On 2019-07-05 16:29, Greg Wooledge wrote:
> On Fri, Jul 05, 2019 at 04:24:42PM +0100, mick crane wrote:
>> 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.
> 
> Have you considered simply *not* deleting all the existing files?  Just
> leaving them alone?

after they get made I rename them all in consecutive order and if 
there's other files in there the number order will get messed up.
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#210786

[Multipart message — attachments visible in raw view] — view raw

On 2019-07-05 at 11:32, mick crane wrote:

> On 2019-07-05 16:29, Greg Wooledge wrote:
> 
>> On Fri, Jul 05, 2019 at 04:24:42PM +0100, mick crane wrote:
>> 
>>> 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.
>> 
>> Have you considered simply *not* deleting all the existing files?
>> Just leaving them alone?
> 
> after they get made I rename them all in consecutive order and if 
> there's other files in there the number order will get messed up.

Then the obvious solution would seem to be: before even starting, check
whether there are any files in the directory that don't match the naming
pattern you expect - or, even more importantly, any subdirectories -
and, if so, abort with an error message and don't do anything.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#210789

On Fri, Jul 05, 2019 at 11:37:13AM -0400, The Wanderer wrote:
> On 2019-07-05 at 11:32, mick crane wrote:
> > after they get made I rename them all in consecutive order and if 
> > there's other files in there the number order will get messed up.
> 
> Then the obvious solution would seem to be: before even starting, check
> whether there are any files in the directory that don't match the naming
> pattern you expect - or, even more importantly, any subdirectories -
> and, if so, abort with an error message and don't do anything.

Or... keep track of the files you created, and only rename *those* files,
not all the files that happen to be in the directory.

Or... give your files the correct names in the first place, so you don't
have to rename them in a second pass.

[toc] | [prev] | [next] | [standalone]

#210793

[Multipart message — attachments visible in raw view] — view raw

On 2019-07-05 at 11:45, Greg Wooledge wrote:

> On Fri, Jul 05, 2019 at 11:37:13AM -0400, The Wanderer wrote:
> 
>> On 2019-07-05 at 11:32, mick crane wrote:
>> 
>>> after they get made I rename them all in consecutive order and if
>>>  there's other files in there the number order will get messed
>>> up.
>> 
>> Then the obvious solution would seem to be: before even starting,
>> check whether there are any files in the directory that don't match
>> the naming pattern you expect - or, even more importantly, any
>> subdirectories - and, if so, abort with an error message and don't
>> do anything.
> 
> Or... keep track of the files you created, and only rename *those*
> files, not all the files that happen to be in the directory.

And what if some of the destination names already exist? That's the
point of deleting the existing files, I'd imagine. (Along with ensuring
that a subsequent program can safely assume that all files in the
resulting directory follow a defined naming pattern and have a defined
relationship to one another, which is one of the few use cases I can
think of for that type of automatic renaming.)

> Or... give your files the correct names in the first place, so you
> don't have to rename them in a second pass.

I'd guess that what names are correct may depend on information that
can't be known at the start of the process.

E.g., if you're wanting the files to be named in sequential numeric
order but zero-padded to the width of the highest-numbered file, you
can't know how many digits of padding you need to add to the first file
until you know how many files will have been created - and that might
not be practically determinable except by actually going through and
creating them.

That would also fit with a likelihood of filename collisions, and with
having it be problematic to just skip the existing filenames and leave
any existing files untouched.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#210795

On Fri, Jul 05, 2019 at 12:16:46PM -0400, The Wanderer wrote:
> And what if some of the destination names already exist? That's the
> point of deleting the existing files, I'd imagine.

You're assuming too much.

Given the communication we've seen thus far, the most likely scenario is
"I have a code snippet that will rename all the files in a directory, so
now I just have to wipe out the directory first, then make the files,
then use this code snippet to rename them all."

If the desired destination files already exist, the only sane thing to
do is abort with an error message, unless the user used a force option.

[toc] | [prev] | [next] | [standalone]

#210798

[Multipart message — attachments visible in raw view] — view raw

On 2019-07-05 at 12:56, Greg Wooledge wrote:

> On Fri, Jul 05, 2019 at 12:16:46PM -0400, The Wanderer wrote:
> 
>> And what if some of the destination names already exist? That's
>> the point of deleting the existing files, I'd imagine.
> 
> You're assuming too much.
> 
> Given the communication we've seen thus far, the most likely scenario
> is "I have a code snippet that will rename all the files in a
> directory, so now I just have to wipe out the directory first, then
> make the files, then use this code snippet to rename them all."

Given that I can't just offhand think of a single reason why doing this
would be desirable, I do not at all consider this even *a* likely
scenario, much less the most likely one.

(I'll probably think of one as soon as I've sent this mail, never mind
by the time anyone replies to it, but c'est la vie.)

> If the desired destination files already exist, the only sane thing
> to do is abort with an error message, unless the user used a force
> option.

Isn't that basically what I suggested in the first place, modulo some
uncertainty about the knowability of what those names will need to be?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#210787

On 2019-07-05 16:32, mick crane wrote:
> On 2019-07-05 16:29, Greg Wooledge wrote:
>> On Fri, Jul 05, 2019 at 04:24:42PM +0100, mick crane wrote:
>>> 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.
>> 
>> Have you considered simply *not* deleting all the existing files?  
>> Just
>> leaving them alone?
> 
> after they get made I rename them all in consecutive order and if
> there's other files in there the number order will get messed up.

I  guess the safest thing would be to keep making new directories called 
the current time
and only delete things by hand but still would be interested if there is 
a solution.
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#210794

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.
> 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).


  songbird

[toc] | [prev] | [next] | [standalone]

#210799

On 7/5/2019 6:31 PM, 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.
>> 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.
>

Answering here to the OP and assuming that the directory path is passed
to the script as argument:

~/ is a shortcut for ${HOME} which is the user home directory.

So ${HOME} will expand to '/home/user', you can simply check for that in
your script.
In a shell script I would do something like:

Take 1:

[ $1 = ${HOME} ] || { echo "   Directory (${1}) not allowed." >&2; exit 1; }
Take 2 (pick one of the two if lines):

if [ $1 != /home/$(id -u) ]; then
if [ $1 != /home/$USER ]; then
    echo "   Directory (${1}) not allowed." >&2
    exit 1
fi


The idea here is to eider only allow a specific directory to work in or
to deny access to some specific directories.
The former is easier to implement.

While you could execute your script in a chroot, not everyone will be
able to use a chroot.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#210801

On Fri, Jul 05, 2019 at 07:39:08PM +0200, john doe wrote:
> > mick crane wrote:
> >> I doing some code in perl and I'm not very good at it.

> [ $1 = ${HOME} ] || { echo "   Directory (${1}) not allowed." >&2; exit 1; }

(a) That's not perl.
(b) https://mywiki.wooledge.org/Quotes
    https://mywiki.wooledge.org/BashPitfalls

[toc] | [prev] | [next] | [standalone]

#210800

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.
>> 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).
> 
> 
>   songbird

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.
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.
I was interested though if there was some instruction to put at the top 
of the file to make perl think that the directory the file was in was 
"/"

mick


-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#210805

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.

[toc] | [prev] | [next] | [standalone]

#210813

On 2019-07-05 20:08, David Wright wrote:
> 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 this is good advice.

-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#210829

On 2019-07-05, mick crane <mick.crane@gmail.com> wrote:
>
> 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 

Not sure exactly what you mean by some software, but you must be sorting
lexicographically (the numbers are treated as strings, in which case
alphabetically speaking 1 goes before 2).

I don't think anybody's pointed this out yet (to my surprise) so I
thought I would (maybe I missed it), although my ignorance is nearly
total in the matter.

> adding to a very large number in the loop and calling them that.
> 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.
> I was interested though if there was some instruction to put at the top 
> of the file to make perl think that the directory the file was in was 
> "/"
>
> mick
>
>


-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 

[toc] | [prev] | [next] | [standalone]

#210832

Curt wrote:
> On 2019-07-05, mick crane <mick.crane@gmail.com> wrote:
...
>> 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 
>
> Not sure exactly what you mean by some software, but you must be sorting
> lexicographically (the numbers are treated as strings, in which case
> alphabetically speaking 1 goes before 2).
>
> I don't think anybody's pointed this out yet (to my surprise) so I
> thought I would (maybe I missed it), although my ignorance is nearly
> total in the matter.

  i have no perl programming experience so i could
not speak to that issue.


  songbird

[toc] | [prev] | [next] | [standalone]

#210833

On 2019-07-06, songbird <songbird@anthive.com> wrote:
> Curt wrote:
>> On 2019-07-05, mick crane <mick.crane@gmail.com> wrote:
> ...
>>> 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 
>>
>> Not sure exactly what you mean by some software, but you must be sorting
>> lexicographically (the numbers are treated as strings, in which case
>> alphabetically speaking 1 goes before 2).
>>
>> I don't think anybody's pointed this out yet (to my surprise) so I
>> thought I would (maybe I missed it), although my ignorance is nearly
>> total in the matter.
>
>   i have no perl programming experience so i could
> not speak to that issue.

This wasn't a criticism of anyone but rather an observation.

In the bash shell I have wondered about this sorting "anomaly" myself and so
looked it up this very day. As the simple (and pretty obvious, really) answer
was completely amenable to my intellectual powers, I was kind of enjoying
myself believing I'd mastered a trivial programming concept and wished to share
my joyful discovery with the group. That it happened to be the result of the
OP's explicit interrogation and so proves itself to be on-topic is a matter of
pure serendipity.

;-)

# sort numerically ascending
my @articles = sort {$a <=> $b} @files;
    
# sort numerically descending
 my @articles = sort {$b <=> $a} @files;

The default must be to sort lexicographically.

>
>   songbird
>
>


-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 

[toc] | [prev] | [next] | [standalone]

#210834

That is certainly an annoying default. Make you have to rethink your naming convention. 

Wolf

Strategic Cybersecurity AdvisoryCloud https://Bit.ly/WolfHalton

> On Jul 6, 2019, at 08:31, Curt <curty@free.fr> wrote:
> 
>> On 2019-07-06, songbird <songbird@anthive.com> wrote:
>> Curt wrote:
>>> On 2019-07-05, mick crane <mick.crane@gmail.com> wrote:
>> ...
>>>> 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 
>>> 
>>> Not sure exactly what you mean by some software, but you must be sorting
>>> lexicographically (the numbers are treated as strings, in which case
>>> alphabetically speaking 1 goes before 2).
>>> 
>>> I don't think anybody's pointed this out yet (to my surprise) so I
>>> thought I would (maybe I missed it), although my ignorance is nearly
>>> total in the matter.
>> 
>>  i have no perl programming experience so i could
>> not speak to that issue.
> 
> This wasn't a criticism of anyone but rather an observation.
> 
> In the bash shell I have wondered about this sorting "anomaly" myself and so
> looked it up this very day. As the simple (and pretty obvious, really) answer
> was completely amenable to my intellectual powers, I was kind of enjoying
> myself believing I'd mastered a trivial programming concept and wished to share
> my joyful discovery with the group. That it happened to be the result of the
> OP's explicit interrogation and so proves itself to be on-topic is a matter of
> pure serendipity.
> 
> ;-)
> 
> # sort numerically ascending
> my @articles = sort {$a <=> $b} @files;
> 
> # sort numerically descending
> my @articles = sort {$b <=> $a} @files;
> 
> The default must be to sort lexicographically.
> 
>> 
>>  songbird
>> 
>> 
> 
> 
> -- 
> "These findings demonstrate that under appropriate conditions the isolated,
> intact large mammalian brain possesses an underappreciated capacity for
> restoration of microcirculation and molecular and cellular activity after a
> prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 
> 

[toc] | [prev] | [next] | [standalone]

#210839

On Saturday, July 06, 2019 08:31:25 AM Curt wrote:
> On 2019-07-06, songbird <songbird@anthive.com> wrote:
> >>> 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

I was just reading something about concrete examples (and my "conclusion" that 
I am a visual thinker that does much better with concrete examples than what 
might seem to me to be either vague or complicated wording.

Thus, I'll show an example of the (usually undesirable) sorting that occurs 
unless the proper approach is taken:  You sometimes will end up with a sort 
that like this:

1
11
12 
...
19
2
21
...
3

(This can be extended to numbers with more digits, all the way up to an 
infinite number of digits, depending on the capability of your software -- 
extending the example is left to the reader.)

I'm sort of hoping the reason is easy to spot, as I am fighting a headache this 
morning and won't try much of an explanation.  (In general, note that all the 
numbers that start with 1 precede any number that starts with 2, and so on.)

As to a solution, I'll leave that for others (or another time) -- I think one 
approach may have already been mentioned in this thread.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web