GitHub - TUVIMEN/torge: A shell script for searching for links on torrent sites
GitHub - TUVIMEN/torge: A shell script for searching for links on torrent sites
It supports thepiratebay, nyaa, 1337x, libgen, limetorrents and rarbg
Pretty cool. May I ask tough, what’s the reason for doing this in BASH and not in something like Python?
Not OP, but I always prefer bash over python since it's "lower level". But that's just a preference.
I'm with this... Bash runs in nearly anything without any real good chance of version conflicts.
Why complicate things needlessly?
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.
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...
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.
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...
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?
-------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()
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.
bash
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=$?
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 :)
Just so you know:
``sh
for bash syntax (dunno what python needs. Probably py or python)
POSIX and shell functions can get us very far indeed. At least, not everthing's an object in Bash. :P
Not really bash but posix shell, the main reason is because at the time of making it i had not yet made python ffi for my html searching lib