4 ms·

I think this idea violates the Unix Philosophy. What should happen is that a separate utility could be used to pipe in the request body to cURL similar to https

I think this idea violates the Unix Philosophy. What should happen is that a separate utility could be used to pipe in the request body to cURL similar to https://stackoverflow.com/questions/12583930/use-pipe-for-curl-data https://stackoverflow.com/questions/12583930/use-pipe-for-cu...

deleted 5y ago
[deleted]
pixl97 5y ago
Unix philosophy is dead. It's body was crucified on the systemd cross.
- deleted 5y ago
  [deleted]
- pphysch 5y ago
  I know systemdphobia is cool, but AWK predates systemd by 3 decades (and the Unix philosophy by 1 year!). Needless to say, the industry found powerful tools like AWK (and SystemD) more useful than rigid dogmas.
  - softwarebeware 5y ago
    AWK was designed by Kernighan who is on the record as subscribing to the Unix Philosophy. For all I know Aho and Weinberger also subscribe to the philosophy. I think its safe to say that AWK and the Unix Philosophy are compatible. I have never seen anything that says otherwise. Was "rigid dogmas" in reference to the Unix Philosophy? I haven't ever seen it described that way.
    - pphysch 5y ago
      My most readily available `man awk` spit out 1235 lines of text. Its namesake physical book is even longer. It is a Turing-complete language. It can execute arbitrary system commands with `system()`. It is the antithesis of the Unix Philosophy. Always has been. And that's okay.
throwawayboise 5y ago
Absolutely. Exactly my sentiments. Formatting JSON is a separate concern from what curl does.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
1vuio0pswjnm7 5y ago
Here is how one might adhere to the so-called UNIX philosophy. Utility #1: 580-character shell script to generate HTTP (NB. printf is a built-in) Utility #2: TCP client to send HTTP, e.g., netcat Utility #3: (Optional) TLS proxy if encryption desired, e.g., stunnel^1 1. For more convenience use a proxy that performs DNS name lookups. Alternatively, use TLS-enabled client, e.g., openssl s_client, etc. Advantages over curl and similar programs: HTTP/1.1 pipelining For the purpose of an example, the shell script will be called "post". To demonstrate pipelining POST requests, we can send multiple requests to DuckDuckGo over a single TCP connection. TLS proxy is listening on 127.0.0.1:80. #! /bin/sh ( y=Connection;n=0;while read x;do x1=${1#*//};x2=${x1%%/*};x3=${x1#*/}; if test x$x3 = x$x2;then x3="";fi; x=$(printf "%s" "${x%%=*}=";echo "${x#*=}"); printf "%s\r\n%s\r\n%s\r\n%s\r\n" \ "POST /${x3} HTTP/1.1" \ "Host: ${x2}" \ "Content-Type: application/x-www-form-urlencoded" \ "Content-Length: ${#x}"; if [ $n -gt 1 ];then printf "%s\r\n\r\n%s\r\n" "$y: keep-alive" "$x";else printf "%s\r\n\r\n%s\r\n" "$y: close" "$x";fi; export n=$((n+1)); done; if [ $n -gt 1 ];then printf "%s\r\n%s\r\n%s\r\n" \ "GET /robots.txt HTTP/1.0" \ "Host: ${x2}" \ "$y: close";fi; ) Put the queries in a file cat > 1.txt q=one q=two q=three ^D Send the queries post https://lite.duckduckgo.com/lite < 1.txt|nc -vvn 127.1 80 Send the queries, save the result, then read the result echo "<base href=https://lite.duckduckgo.com />" > 1.htm post https://lite.duckduckgo.com/lite < 1.txt|nc -vvn 127.1 80 >> 1.htm firefox ./1.htm links -no-connect ./1.htm Based on personal experience as an end user, I find that using separate utilities is faster and more flexible than curl or similar program mentioned in this thread. For me, 1. storage space for programs, e.g. large scripting language interpreters and/or other large binaries, is in short supply and 2. HTTP/1.1 pipelining is a must-have. Using separate, small utilities 1. conserves space and 2. lets me do pipelining easily. I write many single purpose utilties for own use, including one that replaces the "post" shell script in this comment.

deleted 5y ago

[deleted]

pixl97 5y ago

Unix philosophy is dead. It's body was crucified on the systemd cross.

deleted 5y ago
[deleted]
pphysch 5y ago
I know systemdphobia is cool, but AWK predates systemd by 3 decades (and the Unix philosophy by 1 year!). Needless to say, the industry found powerful tools like AWK (and SystemD) more useful than rigid dogmas.
- softwarebeware 5y ago
  AWK was designed by Kernighan who is on the record as subscribing to the Unix Philosophy. For all I know Aho and Weinberger also subscribe to the philosophy. I think its safe to say that AWK and the Unix Philosophy are compatible. I have never seen anything that says otherwise. Was "rigid dogmas" in reference to the Unix Philosophy? I haven't ever seen it described that way.
  - pphysch 5y ago
    My most readily available `man awk` spit out 1235 lines of text. Its namesake physical book is even longer. It is a Turing-complete language. It can execute arbitrary system commands with `system()`. It is the antithesis of the Unix Philosophy. Always has been. And that's okay.

throwawayboise 5y ago

Absolutely. Exactly my sentiments. Formatting JSON is a separate concern from what curl does.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

1vuio0pswjnm7 5y ago

Here is how one might adhere to the so-called UNIX philosophy. Utility #1: 580-character shell script to generate HTTP (NB. printf is a built-in) Utility #2: TCP client to send HTTP, e.g., netcat Utility #3: (Optional) TLS proxy if encryption desired, e.g., stunnel^1 1. For more convenience use a proxy that performs DNS name lookups. Alternatively, use TLS-enabled client, e.g., openssl s_client, etc. Advantages over curl and similar programs: HTTP/1.1 pipelining For the purpose of an example, the shell script will be called "post". To demonstrate pipelining POST requests, we can send multiple requests to DuckDuckGo over a single TCP connection. TLS proxy is listening on 127.0.0.1:80. #! /bin/sh ( y=Connection;n=0;while read x;do x1=${1#*//};x2=${x1%%/*};x3=${x1#*/}; if test x$x3 = x$x2;then x3="";fi; x=$(printf "%s" "${x%%=*}=";echo "${x#*=}"); printf "%s\r\n%s\r\n%s\r\n%s\r\n" \ "POST /${x3} HTTP/1.1" \ "Host: ${x2}" \ "Content-Type: application/x-www-form-urlencoded" \ "Content-Length: ${#x}"; if [ $n -gt 1 ];then printf "%s\r\n\r\n%s\r\n" "$y: keep-alive" "$x";else printf "%s\r\n\r\n%s\r\n" "$y: close" "$x";fi; export n=$((n+1)); done; if [ $n -gt 1 ];then printf "%s\r\n%s\r\n%s\r\n" \ "GET /robots.txt HTTP/1.0" \ "Host: ${x2}" \ "$y: close";fi; ) Put the queries in a file cat > 1.txt q=one q=two q=three ^D Send the queries post https://lite.duckduckgo.com/lite < 1.txt|nc -vvn 127.1 80 Send the queries, save the result, then read the result echo "<base href=https://lite.duckduckgo.com />" > 1.htm post https://lite.duckduckgo.com/lite < 1.txt|nc -vvn 127.1 80 >> 1.htm firefox ./1.htm links -no-connect ./1.htm Based on personal experience as an end user, I find that using separate utilities is faster and more flexible than curl or similar program mentioned in this thread. For me, 1. storage space for programs, e.g. large scripting language interpreters and/or other large binaries, is in short supply and 2. HTTP/1.1 pipelining is a must-have. Using separate, small utilities 1. conserves space and 2. lets me do pipelining easily. I write many single purpose utilties for own use, including one that replaces the "post" shell script in this comment.