It supports thepiratebay, nyaa, 1337x, libgen, limetorrents and rarbg

  • tenchiken@lemmy.dbzer0.comM
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 day ago

    I’m with this… Bash runs in nearly anything without any real good chance of version conflicts.

    Why complicate things needlessly?

    • Rogue@feddit.uk
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      1 day ago

      That’s profoundly untrue. Scripting in bash is an indescribably painful experience.

      You have absolutely no idea what version of a binary the user will be running so you’re limited to using only options that have been well established.

      I’ve never worked with python but I understand it has at least got some semblance of package management providing assurance that methods you’re calling exist, and I imagine it has some standardised mechanism for handling errors unlike bash.

      A simple example is making a GET request to an API and deserializing a JSON response if its successful, handling a timeout if the server can’t be reached or handling the HTTP status code if it’s not a 200 response.

      JS, python, Rust, C#, Java etc will all handle that simple scenario with zero effort but in bash it’s a nightmare.

      • rumba@lemmy.zip
        link
        fedilink
        English
        arrow-up
        2
        ·
        7 hours ago

        So, you don’t know Python at all AND you don’t know Bash, but you feel compelled to talk about how one is so much better than the other?

        1. Python has a lot of compatibility problems, you have to roll the env system and do requirements, and if your distro doesn’t have those packages available, you can’t run the script. Then you can’t always run python 2 code in python 3.

        2. Bash has error handling and try/catch.

        3. Cross platfoming a shell script to run in ba, bash in linux, wsl and mac is fairly straight forward. Worst case, if you don’t have a specific flavor of bash installed, you can always install it. You rely on the posix compliance of the OS binaries to get the job done.

        -------Bash------
        
        #!/usr/bin/env bash
        
        API_URL="https://api.example.com/data"
        
        CONNECT_TIMEOUT=5   
        MAX_TIME=10         
        
        response=$(
          curl \
            --silent \
            --write-out "\n%{http_code}" \
            --connect-timeout "$CONNECT_TIMEOUT" \
            --max-time "$MAX_TIME" \
            "$API_URL"
        )
        
        http_body=$(echo "$response" | sed '$d')        
        http_code=$(echo "$response" | tail -n1)
        
        curl_exit_code=$?
        
        if [ $curl_exit_code -ne 0 ]; then
          echo "Error: Failed to connect or timed out (curl exit code $curl_exit_code)."
          exit 1
        fi
        
        if [ -z "$http_code" ]; then
          echo "Error: No HTTP status code received. The request may have timed out or failed."
          exit 1
        fi
        
        echo "HTTP status code: $http_code"
        
        if [ "$http_code" -eq 200 ]; then
          echo "Request successful! Parsing JSON response..."
          echo "$http_body" | jq
        else
          echo "Request failed with status code $http_code. Response body:"
          echo "$http_body"
          exit 1
        fi
        
        exit 0
        
        
        -------------Python-------------
        #!/usr/bin/env python3
        
        import requests
        import sys
        
        def main():
            # API endpoint
            API_URL = "https://api.example.com/data"
        
            # Timeout (in seconds)
            TIMEOUT = 5
        
            try:
                # Make a GET request with a timeout
                response = requests.get(API_URL, timeout=TIMEOUT)
        
                # Check the HTTP status code
                if response.status_code == 200:
                    # Parse the JSON response
                    try:
                        data = response.json()
                        print("Request successful. Here is the parsed JSON data:")
                        print(data)
                    except ValueError as e:
                        print("Error: Could not parse JSON response.", e)
                        sys.exit(1)
                else:
                    # Handle non-200 status codes
                    print(f"Request failed with status code {response.status_code}.")
                    print("Response body:", response.text)
                    sys.exit(1)
        
            except requests.exceptions.Timeout:
                print(f"Error: The request timed out after {TIMEOUT} seconds.")
                sys.exit(1)
            except requests.exceptions.RequestException as e:
                # Catch all other requests-related errors (e.g., connection error)
                print(f"Error: An error occurred while making the request: {e}")
                sys.exit(1)
        
        if __name__ == "__main__":
            main()
        
        
        
        
        • Rogue@feddit.uk
          link
          fedilink
          English
          arrow-up
          1
          ·
          6 hours ago

          So, you don’t know Python at all AND you don’t know Bash, but you feel compelled to talk about how one is so much better than the other?

          I have plenty of experience with Bash, hence why I was eager to question the implication that bash was less complicated than other solutions.

          You’re correct that I don’t know python, but I do have plenty of familiarity with PHP, JS, C#, and Rust. From my experience with those languages I guessed that python probably has similar libraries for making API calls.

          Thanks for providing the actual examples. Looking at them I’m curious if you still think I’m wrong?

          In my opinion the bash is much more difficult to understand than the python and therefore it’s more likely for bugs to creep in. For example I think curl_exit_code=$? should be called immediately after the curl command as the way it’s presently written isn’t it capturing the exit code of the tail command?

          You’ve explicitly called --connect-timeout and --max-time. imo it only comes from experience that you need to add these options. I had a script that had been funcitoning without issue for months then suddenly started to hang and it was a while before I figured out that the defaults for curl had no timeout so it didn’t gracefully fail like I would expect.

          These are the kind of traps that I fall into all the time with bash and it’s painful to debug.

          response=$(
            curl \
              --silent \
              --write-out "\n%{http_code}" \
              --connect-timeout "$CONNECT_TIMEOUT" \
              --max-time "$MAX_TIME" \
              "$API_URL"
          )
          
          http_body=$(echo "$response" | sed '$d')        
          http_code=$(echo "$response" | tail -n1)
          
          curl_exit_code=$?
          
          • rumba@lemmy.zip
            link
            fedilink
            English
            arrow-up
            1
            ·
            4 hours ago

            have plenty of experience with Bash, hence why I was eager to question the implication that bash was less complicated than other solutions.

            You said “Scripting in bash is an indescribably painful experience.”

            That’s an opinion, and it’s certainly yours to have. In my experience, neither of those solutions to the problem you suggested are all that complicated.

            In my opinion the bash is much more difficult to understand than the python and therefore it’s more likely for bugs to creep in.

            You could say this about any language/script, it’s all about our individual experiences.

            That’s a great catch on the $?, sadly, I just handed you copypasta i glanced at them to make sure they looked decent before posting. If you swap it around it appears to run fine. You’ll also need to install / use jq to do the proper json parsing.

            imo it only comes from experience that you need to add these options

            it’s optional in the python too. You can also use the OS builtin “timeout” when calling a command to generically kill it off if it doesn’t exit in a timeframe.

            Sure, I’ve done some scary things in bash before. Some of them went to production. :) timeout tail -f > output to grab x seconds of a log for monitoring.

            IMHO, Bash is fine (and rapid) up to a point. It’s available on all flavors of Linux/Unix, with some minor attention to Posix, you can make it run efficiently on most anything (except maybe fish, had a couple of devs that REALLY swore by fish, but it wasn’t nice about syntax.)

            Bash is more available without privilege and more backward compatible. It does lack finess and utility for larger projects. At some point, you need to do things that are better managed in Python libraries.
            I would not want to attempt a proper web server CGI in bash, nor try heavy math.

            Bash is nice because you’re using OS binaries behind the scenes to do the heavy lifting. They’re all written in something optimized and beefy. It’s like you get to use all the power and stability of C projects with the duct tape speed and efficiency that surpasses most of the scripting languages. It’s a hell of a lot easier to do system calls in bash than py :)

      • tenchiken@lemmy.dbzer0.comM
        link
        fedilink
        English
        arrow-up
        5
        ·
        1 day ago

        I didn’t say it wasn’t painful, merely convenient for me.

        I’m fine sticking with well established. Why would I need package management with a shell script? Bash has as many ways of handling errors as I give it. All this you mention are using functionality I can address in other ways but again, I never claimed it solved everything. I only prefer it due to knowing that if I solved the problem in bash, it stays solved for me.

        Show us on the doll where the shell script touched you…

        • Rogue@feddit.uk
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          1
          ·
          1 day ago

          Show us on the doll where the shell script touched you…

          Everywhere.

          I believed bash would be enjoyable, I believed we’d have fun. But all it ever gave was pain. I was young and naive.

          • tenchiken@lemmy.dbzer0.comM
            link
            fedilink
            English
            arrow-up
            3
            ·
            1 day ago

            Hah! Indeed.

            I feel it’s the known pain at least. I’ve had python and perl pain as well, and it’s not as comforting a pain to me.

            Hello Darkness, my old friend… I’ve come to script with you again…