• (nodebb)

    All shell script languages tend to be bad

  • ch (unregistered)

    Shame that the new code is still wrong. Try: WORKINGDIR=a/b/c/../d WORKINGDIR=a/b WORKINGDIR=a/b//c WORKINGDIR=a/b/c/

  • Dlareg (unregistered)

    Why would the program receive the .. in the pathname, doesn't the shell expand that?

  • Paul (unregistered)

    not really a wtf if it did exactly what was required though, more of a convoluted way.

    Saying that, I don't understand the replaced version and maybe neither would the original author.

    Whats wrong with changing the current dir to the working dir, going up 2 levels and then setting SYSDIR = current dir before going back to the original dir?

  • Zach (unregistered) in reply to Paul

    Well, you can't go up 2 directories because you can't use ..

  • (nodebb)

    To be fair, if the script is really old it probably predates those shell variable operators.

    But the dirname command has been around for ages, so

    UPONE=dirname "$WORKINGDIR" UPTWO=dirname "$UPONE"

    Addendum 2019-02-06 08:29: Hmm, what happened to my backticks and newlines? Is code formatting available in these comments?

  • Brian (unregistered) in reply to Zach

    It says the program can't use "..". Nothing wrong with the script manipulating the path however it likes as long as the output is correctly formatted.

  • DFYX (unregistered)

    Simple and easy to understand:

    export SYSDIR=$(realpath ${WORKINGDIR}/../..)

  • some_guy (unregistered)

    But... export WORKINGDIR='$SYSDIR/last/part'. The real WTF is that SYSDIR was calculated at all.

  • Unix History (unregistered)

    If you've got FORTRAN around, you probably have an ancient artifiact version of Unix. And no GNU coreutils or installed open source software from the Internet. So, how would you implement this in "sh" or "csh" without having ksh, bash or tcsh or the readline library?

  • (nodebb)

    export SYSDIR=$(dirname $(dirname ${WORKINGDIR}))

  • Brian Boorman (google) in reply to Unix History

    Maybe not. Fortran compilers exist for both Linux and Windows (though this article is certainly not talking about a Windows system). There is no up-front reason that the old application couldn't have been compiled on a newer Linux system. It also seems reasonable that in that case they were told not to alter the Fortran code and to use it.

    So, the WTF is that the script implementer was not well-versed in shell commands.

  • Somebody Somewhere (unregistered) in reply to Brian Boorman

    Yep, Just because we're running Ubuntu 2052.10 ("Sauntering Seacucumber") doesn't mean that FORTRAN 77 can't still be compiled.

  • -to- (unregistered)

    Write a Fortran code that processes some data and spits out gnuplot instructions on stdout, pipe into gnuplot to make figures. Write a shell script that generates LaTeX to bind the heap of figures into a pdf. Generate, print, distribute to the team , brainstorm.

    Go back to your office, look at your creation, and, in a fit of disgust, start learning python/matplotlib.

    Btw Fortran (gfortran, ifort...) is very much a thing of cutting-edge systems today. Compiles 40-year-old code flawlessly, and if you want to go OO and whatnot, there's Fortran 2003 and up.

  • John (unregistered)

    I've compiled coreutils from source on an old distro. Perhaps they could to the same.

  • DataGhost (unregistered)

    TRWTF is that AFAIK, . and .. are features of the filesystem/os and the application needn't/can't worry about them as they appear as regular directories. Why would it not work?

  • (nodebb)

    Nothing wrong with Fortran IV (aka Fortran 66).

    Then again before that was Fortran II, and before that "Fortran with Format".

    Yes, I have programmed in all of these.

  • sizer99 (google)

    Nearly all of sh/bash is a WTF at this point, with 42 years of accumulated cruft and outrageous syntax doing far more than it was ever intended to do. And I say this as someone who has hundreds of lines of bash code in an embedded device for managing configurations and options.

  • Hasseman (unregistered) in reply to herby

    Yep, remember to fake else clauses with negation of If and goto's as else did not exists in Fortran 66 ...

  • Carl (unregistered)

    Hey, OP here. Mainly I was trying to deduce what the script did so as to replace it with something more intuitive.

    I did consider the double dirname and also WORKDIR=$(readlink -f $WORKDIR/../..), after all I needed it more readable. But in the end I didn't want to change functionality. The original code did only String manipulation to remove everything from the second-to-last slash to the end, so that's what I decided to do.

    Thanks

  • P (unregistered)

    CarlSagan42, is that you?

  • Schily (unregistered)

    This only works on non-POSIX implementations like GNU bash

  • 7eggert (unregistered) in reply to Carl

    I'd use sed as it's (as far as I observed) universally available.

  • FORTRAN user. (unregistered) in reply to Unix History

    I have to disagree. I personally use FORTRAN, as part of GCC, on quite modern unix-like OSes, such as CentOS and Ubuntu.

  • jay (unregistered)

    A sufficiently skilled programmer can write a FORTRAN program in any language.

  • markm (unregistered)

    Jay: But the arithmetic won't run as fast in most other languages. That's one reason FORTRAN is still around; it is optimized for math on huge datasets in a way no other language has ever been. The other reason is legacy code, especially the scientific and statistical libraries that have never been translated to a modern language.

  • Klaus (unregistered)

    How about readlink -m to normalize the paths?

  • Stefan (unregistered)

    You also seem quite confident WORKINGDIR doesn't end with a slash:

    WORKINGDIR=/tmp/z/a/ SYSDIR=${WORKINGDIR%//}

    echo "wdir=$WORKINGDIR sys=$SYSDIR"

    wdir=/tmp/z/a/ sys=/tmp/z

  • Arneb (unregistered) in reply to Brian Boorman

    Nah, it's research. People in scientific computing are notorious for gladly running massively parallel versions of Fortran 77 apps on multi-million-dollar clusters; those machines almost universally run Linux, typically Red Hat or CentOS.

Leave a comment on “Double Up”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article