• (cs)

    Bruce M. should have made an auto-generator for the retry_force_upload script. That way he could easily tune the number of forced uploads depending on the network load, weather conditions, etc.

    <font face="Courier New" size="2">#!/bin/sh
    # AUTOGEN (TM)
    # A script to automatically generate a retry_upload_site script
    # Usage: autogen [number]

    # Version 10.0 (Final)
    # Added support for numbers 901-1000

    # snip................

    # ................ snip    

    # Version 3.0
    # Added support for numbers 201-300

    # Version 2.0
    # Added support for numbers 101-200

    # Version 1.0
    # Supports numbers 1-100

    Number=$1
    File="./retry_upload_site"
    UploadScript="./upload-site"
    echo "#!/bin/sh" > $File
    echo "# This file is auto-generated by AUTOGEN 10.0 (TM)" >> $File
    if [ $Number = 1 ]; then
        echo "$UploadScript" >> $File
    elif [ $Number = 2 ]; then
        echo "$UploadScript" >> $File
        echo "$UploadScript" >> $File
    elif [ $Number = 3 ]; then
        echo "$UploadScript" >> $File
        echo "$UploadScript" >> $File
        echo "$UploadScript" >> $File
    # snip................

    # ................ snip    
    elif [ $Number = 1000 ]; then
        echo "$UploadScript" >> $File
        echo "$UploadScript" >> $File
        echo "$UploadScript" >> $File
        echo "$UploadScript" >> $File
        echo "$UploadScript" >> $File
        echo "$UploadScript" >> $File
    # snip................

    # ................ snip
        echo "$UploadScript" >> $File
        echo "$UploadScript" >> $File
    else
        echo "Unsupported number, contact your administrator"
    fi
    </font>

  • PHP hater (unregistered) in reply to seymore15074
    seymore15074:
    snoofle:

    Richard Nixon:
    richleick:


    And for you Java purists out there, i'm sorry, but the { SHOULD be on a seperate line!


    No, it should not.

    sincerely,
    Richard Nixon

    Let's be thankful that there aren't "C"-style #define's in Java, or there'd be folks doing stuff like this:

    #define then
    #define begin {
    #define end }
    if (x > y) then 
       begin 
         blah; 
       end;
    

    (Once, on a bet, I wrote a Pascal/C translator doing most of the work with #define statements)

    I always preferred to write the "begin" on the same line in Pascal, too.  There is no need to start a block on an empty line because the indent denotes the start of a new block...

    Didnt that get posted as a WTF here?

  • (cs) in reply to ammoQ
    ammoQ:
    Anonymous:

    echo "./upload-site&./upload-site&">>upload-site && ./upload-site # ;-)



    16 years ago I tried exactly that on a SCO Unix PC. After some minutes, the terminal started outputting weird charaters. Needless to say that the power switch was the only way to stop it.

    ROFL LOL ROFLMAO Hahahahahahahahahahaha! WTF?

  • rp (unregistered) in reply to Enric Naval

    while ./upload_script; do :; done

  • rp (unregistered) in reply to rp

    augh. (this is my reward for posting about shell scripts while waiting for visual studio to do its magic). retry:

    while true; do ./upload_script || break; done

    (tested this time)

  • TC (unregistered) in reply to EvanED
    EvanED:

    I do it because it's possible to see at a glance if all braces are closed.


    Only if you can vertically align braces in your head over 30 lines. With tabs at 4 chars or less (don't get me started on tabs). I never look for {s. And since half-decent text editors will highlight ifs and fors, the opening { doesn't really matter.

    Personally, it just wastes space and dissociates the block from the statement. And if it makes sense to go
    if (a)
        b;
    then obviously with a block, it looks like
    if (a)
        {
           b;
        }
    unless blocks don't automatically increase indent level, in which case gratituous blocks (i.e. to limit the scope of local variables) don't change the formatting at all.

    For my third-year project I think I'll work on a text editor that automatically hilights missing }s for you.

    I'm also a big fan of "always use a {", leading to my one-line "if (a) { b; }". Sometimes it makes sense, like for error handling in C. Or anything short. (missing }s are occasionally a pain).

    captcha: stfu


  • (cs) in reply to TC
    TC:


    then obviously with a block, it looks like
    if (a)
        {
           b;
        }


    IIRC GNU programs use this indention style.


    I'm also a big fan of "always use a {", leading to my one-line "if (a) { b; }". Sometimes it makes sense, like for error handling in C. Or anything short. (missing }s are occasionally a pain).



    Don't forget macros in C:

    /* stupid but possible */
    #define a(x) b(x);c(x)

    int x() {
      if (0==1) a(3);
    }


    executes c(3).
  • RichiH (unregistered)

    Well, that script should run slightly faster than emerge sync..

  • Jason (unregistered) in reply to Dazed

    Hmm.  Writing 'C' structure accessor macros for a weird, 24-bit hybrid 1MHz processor that goes into an implanted medical device?  Although, in truth, our underlying architecture is so feeble that pretty much everything we write turns into pigs' ears, so you may not be off the mark.  Can you say "global variable hell?"  (I sure can!)

    Honestly, though, I think that Emerson was prescient in this instance.  I mean, the original description indicated that the author knew that the upload wouldn't work sometimes, so just reapplying the same, known-to-be-poor solution, sounds a pretty accurate implementation of Emerson's maxim.

    ---Jason

  • Jason (unregistered) in reply to Dazed

    I apologize for that last post.  Here's the context in which it was written.

    Anonymous:
    Anonymous:

    Wasn't it Emerson who said something to the effect of:

    "A foolish consistency is the hobgoblin of little minds?"

    Yes. It would however be wise to bear in mind that Emerson was a poet, not a programmer. Nearly every time I've heard that quotation, it's been trotted out by someone who has just made a pig's ear of something. So what were you just doing before you made that post? ;-)

    Hmm.  Writing 'C' structure accessor macros for a weird, 24-bit hybrid 1MHz processor that goes into an implanted medical device?  Although, in truth, our underlying architecture is so feeble that pretty much everything we write turns into pigs' ears, so you may not be off the mark.  Can you say "global variable hell?"  (I sure can!)

    Honestly, though, I think that Emerson was prescient in this instance.  I mean, the original description indicated that the author knew that the upload wouldn't work sometimes, so just reapplying the same, known-to-be-poor solution, sounds a pretty accurate implementation of Emerson's maxim.

    ---Jason

  • Bob (unregistered) in reply to Richard Nixon
    You're developing in something that doesn't do that for you? And, if yes, why?

    sincerely,
    Richard Nixon


    Because vi is the only editor I know of that's virtually universally available on machines in the field. ssh, edit, fix, rerun, rinse and repeat is so much simpler if your code is written is such a way that you can easily edit in vi.
  • (cs) in reply to Bob
    Anonymous:
    You're developing in something that doesn't do that for you? And, if yes, why?

    sincerely,
    Richard Nixon


    Because vi is the only editor I know of that's virtually universally available on machines in the field. ssh, edit, fix, rerun, rinse and repeat is so much simpler if your code is written is such a way that you can easily edit in vi.


    The % command shows matching brackets in vi, should be good enough to check if the first { matches the last }
  • (cs) in reply to Bob
    Anonymous:
    You're developing in something that doesn't do that for you? And, if yes, why?

    sincerely,
    Richard Nixon


    Because vi is the only editor I know of that's virtually universally available on machines in the field. ssh, edit, fix, rerun, rinse and repeat is so much simpler if your code is written is such a way that you can easily edit in vi.


    You might have it universally available to you but you don't have a grasp of how to use it apparently. vi has the functionality that you claim it does not.

    sincerely,
    Richard Nixon
  • (cs) in reply to Felipe

    Anonymous:
    Alex:
    Below are the unedited, full contents of "retry_upload_site"


    The Real WTF is that the code is not commented !

    Like /* before the first line, and */ after the last one?

  • (cs) in reply to dcturner
    dcturner:
    Anonymous:
    Proper way to code this sort of thing:

    while [[ 1 ]]; do echo "./upload-site" >> script; ./script; done

    Like, duh.



    Nonono, that will only run ./upload-site  inf*(inf-1)/2 times which isn't nearly enough. Perhaps



    echo "./upload-site" > script; while [[ 1 ]]; do cat script script >> script2; mv script2 script; ./script; done

    "TheDailyWTF.com - for when aleph-0 just isn't infinite enough"

  • (cs)

    As an Intel(tm) Core 2 Duo(r) Certified Developer, let me add this: All of the previously posted approaches make insufficient use of the new and exciting MultiMultiMultimedia(r)-ready Intel(tm) Core Duo(r) Dual Core Processing Capabilities(r).

    Clearly, we need a solution that can make use of whatever Symmetric Multiprocessing Resources(r) it can find, a solution that scales right up to the largest supercomputers ever built in human history.  A solution like this:

    >script-b
    echo ./upload_site >script-a
    while true; do
      cat script-a >>script-b
      cat script-b >>script-a
      ./script-a &
    done

  • Craig (unregistered) in reply to Enric Naval

    <font face="Arial">Alternately:</font>
    <font face="Courier New">
    while : ; do
        if ./upload_script ; then break; fi
    done</font>

    <font face="Arial">or even:</font>
    <font face="Courier New">
    while ./upload_script ; do : ; done


    (The :' command in Berkley compatible shells is a shell built-in equvalent to /bin/true . While most shells treattrue' as a synonym for : and don't exec() a new /bin/true process, it's best not to rely on it. Explicit /bin/true always exec()s a new process. Don't use it.)
    </font>

Leave a comment on “If at first you don't succeed...”

Log In or post as a guest

Replying to comment #:

« Return to Article