News for hackers. Stuff that matters.
Re:Problem solving with Unix commands by dnet on Thursday February 14, 2019 @05:27AM (#19160875)
Removing leading zeroes doesn't require Python. One easy solution would be sed:

    $ echo -e '0001\n0010\n0002' | sed 's/^0*//'
    1
    10
    2
Re:Problem solving with Unix commands by mshook on Thursday February 14, 2019 @05:33AM (#19160898)
Yeah plus seq can generate sequences with leading zeroes (something like seq -f %04.f 1 20).

So instead of scripting, he could have generated a sorted list of numbers from the files he had. Created a file with the sequence of numbers for the range and diffed/commed the whole thing. Voilà...

Re:Problem solving with Unix commands by pwg on Thursday February 14, 2019 @08:22AM (#19161622)
The seq provided in the GNU toolset has a -w flag to turn on "equal width" mode, so one can also get zero padded numbers out (from GNU seq) by turning on that mode and zero padding the input:

    $ seq -w 0001 0003
    0001
    0002
    0003
    $
Re:Problem solving with Unix commands by anc84 on Friday February 15, 2019 @04:01AM (#19169494)
Nice, this works automatically like this:

    $ seq -w 98 102
    098
    099
    100
    101
    102
Re:Problem solving with Unix commands by lelf on Thursday February 14, 2019 @05:37AM (#19160915)

  seq -f %04g 0 3
  echo {0000..0003} # if bash
Re:Problem solving with Unix commands by v3gas on Thursday February 14, 2019 @05:38AM (#19160923)
Did not know that. Thanks! That's much easier.
Re:Problem solving with Unix commands by leblancfg on Thursday February 14, 2019 @08:54AM (#19161830)
Yes. Or if you're going to whip out Python, might as well make it all in Python.
Re:Problem solving with Unix commands by masklinn on Thursday February 14, 2019 @03:08PM (#19165491)
Very much my thinking, especially when there are no significant commands you need to shell out to:

    import sys, pathlib
    basedir = pathlib.Path(sys.argv[1])
    for i in range(1, 501):
        if not (basedir / f'{i:04}_A.csv').is_file():
            print(i)
Re:Problem solving with Unix commands by hellabites on Thursday February 14, 2019 @04:54PM (#19166437)
Just for fun some bash:

    for k in $(seq -f %04.f 1 501); do 
        f="${k}_A.csv"
        ! [[ -f "$f" ]] && echo $f || :
    done
or more succinctly,

    for k in {0001..0501}_A.csv; do
        ! [[ -f "$f" ]] && echo $f || :
    done
and if you have GNU parallel installed:

    parallel -kj1 '! [[ -f "{}" ]] && echo {} || :' ::: {0001..0501}_A.csv
Re:Problem solving with Unix commands by v3gas on Thursday February 14, 2019 @04:03PM (#19165987)
Nice one!
Re:Problem solving with Unix commands by jraph on Thursday February 14, 2019 @09:03AM (#19161898)

    $ echo -e '0001\n0010\n0002\n0' | bc
    1
    10
    2
    0
Re:Problem solving with Unix commands by hellabites on Thursday February 14, 2019 @06:31PM (#19167104)
This is better relative to the `sed` solution as it handles the `0000` case well.
Re:Problem solving with Unix commands by jfk13 on Thursday February 14, 2019 @08:53AM (#19161824)
If one of the items is actually zero, this would delete it entirely, which probably isn't the desired result.
Re:Problem solving with Unix commands by neokantian on Thursday February 14, 2019 @06:02AM (#19161023)
Yeah, no need for Python. Even the following seems to work fine:

$ printf "%d\n" 003

3

Re:Problem solving with Unix commands by scbrg on Thursday February 14, 2019 @08:28AM (#19161661)
Well, that works up to a point. Fore some, that point might be considered a bit too close to zero...

    $ printf "%d\n" 009
    sh: 1: printf: 009: not completely converted
    0
Re:Problem solving with Unix commands by jandrese on Thursday February 14, 2019 @11:23AM (#19163087)
0-prefix octal notation continues to be a mistake.

I love when programs mysteriously fail when passed an IP address like 192.168.001.009.

Thankfully modern tools have been moving away from supporting that notation and are less likely to explode all over unsuspecting users.

Re:Problem solving with Unix commands by neokantian on Thursday February 14, 2019 @11:30AM (#19163150)
Yes, you are right. This seems to work better:

$ printf "%1.0f\n" 009

9

$ printf "%1.0f\n" 00125990

125990

Re:Problem solving with Unix commands by lelf on Thursday February 14, 2019 @09:51AM (#19162238)

  $ printf %d 010
  8
Re:Problem solving with Unix commands by eMSF on Thursday February 14, 2019 @10:52AM (#19162779)
Given the situation in the article, you might as well do this:

  ls ????_A.csv | grep -o '[1-9][0-9]*'
Re:Problem solving with Unix commands by v3gas on Thursday February 14, 2019 @05:29AM (#19160881)
Oh nice. sed still scares me a bit.
Re:Problem solving with Unix commands by dahart on Thursday February 14, 2019 @10:06AM (#19162343)
Definitely check out perl one liner patterns. Perl is less scary and more powerful and usually almost as short as sed commands. Perl can often replace pipelines that use both sed and awk. Perl one liners need judicious flags though, common patterns look like perl -ne, perl -pie, perl -lane ... these do very different things. Once you know them, it’s like a minor superpower.
Re:Problem solving with Unix commands by SomethingOrNot on Thursday February 14, 2019 @06:48AM (#19161184)
I’m not terribly experienced with Unix tools but I reckon that it might be best to just use Perl instead. Then you just have to worry about PCRE instead of PCRE in addition to old-style regexps.

Then again, Perl is even scarier.

Re:Problem solving with Unix commands by jabl on Thursday February 14, 2019 @07:56AM (#19161500)
perl one-liners are pretty powerful and can replace awk/sed/cut/tr/etc. That being said, then you have to remember which command-line options you should give perl (was it -lane to do X, or was it -pie, or something else entirely?).

But yeah, the perl rabbit hole goes as deep as you want to, and in some sense it makes it more difficult to say "screw it, I'm redoing this in a real language" as complexity rises. And then you end up with a thousand lines of line noise.

Re:Problem solving with Unix commands by b2gills on Monday February 18, 2019 @06:42PM (#19195530)
Well Perl is a real language, so of course it makes it more difficult to say “screw it, I'm redoing this in a real language”.

That said the Perl that you write in a one-liner should be different than the Perl that you write when the complexity rises.

If you have more than a few hundred lines, you probably need to move some of it out into a module. There should also be tests for that module. It might even make sense to structure it like a CPAN module so that you can use the existing tools to test and install it.

Re:Problem solving with Unix commands by jabl on Thursday February 21, 2019 @02:57PM (#19220027)
I have to admit the last time I wrote anything larger than short scripts in perl was in the perl 4 period (on HP-UX to boot). I eagerly awaited the perl 5 version of the Camel book, but in the end I jumped ship to python before getting seriously into perl 5.
Re:Problem solving with Unix commands by SomethingOrNot on Thursday February 14, 2019 @08:05AM (#19161543)
I haven’t coded Perl beyond one-liners. What attracts me to it are its regular expressions. So much of Unix scripting seems to involve regexps. So I figure Perl+utilities is the better option compared to utilities+Bash.

I wouldn’t wanna use it for more than short scripts. Perl 6 might be fun, but it doesn’t seem to have a large enough community.

Re:Problem solving with Unix commands by b2gills on Monday February 18, 2019 @07:15PM (#19195693)
If you want to improve your coding skills you should read “Higher Order Perl”. (made available for free online by the author)

If you want to improve your Perl code read “Modern Perl”. (There is more than one version, and I know the first version was made freely available online)

Perl is a better language for large codebases than most people give it credit for. That said it allows more creativity when it comes to your code. So you can make awful code just as easily as beautiful code. Perl6 makes the beautiful code easier to write and shorter, while making awful code a bit harder to write.

Re:Problem solving with Unix commands by chromatic on Tuesday February 19, 2019 @04:55PM (#19203237)
> There is more than one version, and I know the first version was made freely available online

Good news! Every version is freely available online. Here's the most recent:

http://modernperlbooks.com/books/modern_perl_2016/index.html

Re:Problem solving with Unix commands by ianai on Thursday February 14, 2019 @05:55AM (#19160987)
It’s useful but highly cryptic in my usage.