At least in Heyuri★CGI's case, we don't write anything from scratch - we modify existing scripts written by various nihonjin, usually from 20+ years ago

Some of those authors wrote guides (some even wrote books), but they're presumably very outdated and full of bad practices

what are your purposes? if u have previous l33t experience, I'd just install similar cgi scripts to what you want to achieve and do tweaks. But it's probably too much work for little worth when AI exists

if you already know how 2 program but just don't know perl, chatgpt + search-engine can get you most of the way for simple modifications. But either way, teh best way is to just give perl a go even if you're a n00b at it. Since experience/practice will make you good at it given enough time

>>147921
as some one who owns and read thu the alpacha book (not read camle book)
so long as you know programing and unix and shell (shell tools like sed grep (regex)) you can start going.
its really similar to shell and the worse parts are the "automatic" things like $_ and stuff. it uses $ for a var
% for a table/associative table
it has awful function syntax too. its really a lot like shell but kinda worse imho

i dont know oop, the allpacha says shit like perl can support other langauges but man its a bitch, you prob gonna have to work with perl moduels and know simple pakage mange stuff that chatgpt can help with, honestly have chatgpt hold ur hand with things like that but its really just a coked up shell lang. kinda like php!

>>147921
>All of you BBS hackers of Heyuri, where have you learnt your Perl?
ah i should have awnserd. trial and error trying to help /cgi/ with new stuff and already knowing programing. i want to learn perl as its kool and openbsd supports it natively fully (there pakage manager was written in perl) and i thought there would be a hand full of jobs maintainng this shit
tho i never used it on openbsd. and setting up web shit for perl sucks, i thought there would be ton of guids to get perl working with nginx or apachie (since it use to run the whole web at one point) but there is nothign and it a pain.

another thing. cgi just means commen gateway interface. and what that means is. user parameters come from std in and html goes std out
so you could write c programs and put them in a cgi bin and have them execute and work. https://learnbchs.org/

why did CGI scripting die off anyway? it seems perfectly serviceable for software like this

>>147988
program in perl and tell me! cgi scripting is not bad. php is still cgi. its the most simplest way to make dynamic pages. but outside of nginx or apachi.
ppl use different web servers with there own way, like go's web server or flask in python or spring boot's web server. each still do read http protocol (witch is still plane text, u can use telnet and see) and put raw text and get raw text out, they just digest it all difrently and its more frame work centric then just using any old language and reading stdin and pumping stdout.aka the frameworks dont think of it as stdin and stdout. shit even lareval a php framwork, its just so far from thinking and using it in a stdin/stdout way that you prob could not consider it to be cgi with how you have to use it

>why did CGI scripting die off anyway? it seems perfectly serviceable for software like this
I don't know teh technicalities, but it seems to have inherent limitations regarding "live" updates and things of that nature

Here's something from teh interwebz circa 2018: https://www.perl.com/article/perl-and-cgi/#why-not-to-use-cgi

So, why did CGI drop from “state of the art” to discouraged by its own maintainers?

There are two big issues with CGI: speed and complexity. Every HTTP request triggers the forking of a new process on the web server, which is costly for server resources. A more efficient and faster way is to use a multi-process daemon which does its forking on startup and maintains a pool of processes to handle requests.

CGI isn’t good at managing the complexity of larger web applications: it has no MVC architecture to help developers separate concerns. This tends to lead to hard-to-maintain programs.

The rise of web frameworks such as Ruby on Rails, and the application servers they run on, have done much to solve both problems. There are many web frameworks written in Perl; among the most popular are Catalyst, Dancer, and Mojolicious.

CGI also contains a security vulnerability which must be coded around to avoid parameter injection.

>>147994
>Every HTTP request triggers the forking of a new process on the web server
look up fastcgi
>it has no MVC architecture
framework issue not a protocol issues. see php and php larevel
>CGI also contains a security vulnerability which must be coded around to avoid parameter injection.
u have to do that anyways in any lang where you want to save and use user data.

it being "slow" or not scalable is quite retarded. take any modern nu web app vs some ol cgi bin, it rapes the nu web app in speed over and over.

now the issue with it being live (or i assume reactive/restful, that is just mixing js with some json end point)cgi can do that. now if you mean websockets, yeah cgi cant really do that and its not really even http to begin with but you can use websocketd and its basically the same as cgi scripting as you read std in and send msg to std out