Other What's the go-to scripting language to learn for general purpose-scripting on freebsd?

M

Michael Warren

With my previous linux operating systems i've used C for literally the simplest tasks... pretty much always overkiled tasks that should require scripting with a high level language. wasted so much time writing c to say the least... I always knew it wasn't the way to go in the future so after picking up freebsd i wanted to start a new chapter and try to learn how to do things the right way and learn by the books the things that i always overlooked and ignored in linux.

the freebsd handbook has been an amazing resource so far and i wanna proudly say that i'm begining to transition from asking aichatbots for answers to reading the handbook and getting my answers from the source instead.
i hope i didn't deviate much from the title but i wanna what's the go-to scripting language that evreybody endorses on freebsd and maybe the other bsd's in general too ?
 
+1 for sh and awk

If you are coming from C you might also want to look at Perl - it's sometimes described as a bastard between C, various shells and awk. So if you feel that shell and awk won't do it and C is still overkill, Perl usually fits that niche. Yes, there are those jokes that perl is unreadable, but only if you force it that way - IMHO most perl code is still much cleaner, of higher quality and MUCH less bloated than 90% of python code out there...
For portable, quick scripting however, bourne shell and awk are the way to go, as they are available on all UNIX-descendands and on linux - although in linux-land they usually don't know the difference between sh and their bash and produce a lot of non-portable code, so beware of stuff you find online, as they usually write bash yet still put a '#!/bin/sh' at the beginning.
 
Personally, I use /bin/sh for all my scripts, but I'm not very pleased with that thing.

First because it's hard to code, that's not a language as such. Also, you may think you will never have any problem as it is in base, but as the behaviour of some utilities changes through the FreeBSD versions, in fact you get trouble anyway.

There is lua in base. For example, the pkgbasify script is lua code. Never had the time to explore lua, but it can't be as repulsive as sh.
 
eralash said:
This may not be the best advice.

Yes, lua is present in the base system, but only as an internal service tool. Its usage as a general-purpose programming language is not recommended. If you want to use lua for user scripts, you should install lua from the ports collection.
Click to expand...
As I said, this need some investigations. Unless I'm mistaken, some parts of the FreeBSD startup are written in lua. Very important scripts like pkgbasify are, as well. Isn't recommended by who and why?
Why install a package since it's in base? What are the differences between these two versions?
 
Emrion said:
As I said, this need some investigations. Unless I'm mistaken, some parts of the FreeBSD startup are written in lua. Very important scripts like pkgbasify are, as well. Isn't recommended by who and why?
Why install a package since it's in base? What is the differences between these two versions?
Click to expand...
If I understand / recall correctly, in-base lua is kinda subset and (not officially, though) called "flua" (FreeBSD lua). Flua is introduced for loader to take place in Forth, as of maintainability (short in maintainers for Forth).
And if I'm not overlooking, pkgbasify is not yet in base, means, possibly rewritten in C or something else. Also, safe "unpkgbasify" would be wanted.
 
eralash said:
There are only two fundamental programming languages: C and Shell. Because the world is written in C, and Shell makes the world work for you.

Other programming languages just occupy their own specific niche.
Click to expand...
This sound very comforting to me because i got C already out the way. The easier scripting language is all what's left to learn is what i understood from the reply !
And i can't ignore awk and perl anymore after finding out about them. It won't hurt to learn just the basics and then decide if they will fit my needs .
 
mer said:
You are not mistaken. Loader that used to be written in Forth was rewritten to lua. If you look in /boot you can still find everything.
Click to expand...
Yes. As loader_lua is larger than loader_4th, some embedded devices would be too short in ROM to hold loader_lua. And there could be customized Forth scripts for loader in the wild and having no one who can port them to lua.
 
The typical scripting languages like Python, Ruby, TCL and Perl have some problems in common:
  • Multithreaded code doesn't spread to multiple cores
  • No compile-time type checking
  • About 80 times slower than C, which together with using only a single core is pretty excessive.

The most practical language around that is Go.

Having said that, if you don't knew bourne shell yet, that is probably the first to learn.
 
cracauer@ said:
  • Multithreaded code doesn't spread to multiple cores
  • No compile-time type checking
  • About 80 times slower than C, which together with using only a single core is pretty excessive.
Click to expand...
Take it as the price of writing fast without many lines of code some program you urgently need.

Of course, to be able like Brian Kernighan (and perhaps the OP) to do quickly in C what one needs would be fantastic. Look what he says against tcl:

The split into two components was encouraged and ultimately forced by two issues. First, Tcl's notation for arithmetic expressions is clumsy; it is easier to write most expressions in C. More important, however, Tcl is not very good at data structures, since it provides only associative arrays and strings (upon which a veneer of linked lists can be applied). Again, C or C++ is more expressive and the code is much easier to maintain. These operations also run significantly faster in C/C++; this more than compensates for any extra file traffic.
Click to expand...

Who says Tcl sucks...

Tclers wiki
wiki.tcl-lang.org wiki.tcl-lang.org
 
cracauer@ said:
About 80 times slower than C, which together with using only a single core is pretty excessive.
Click to expand...
These things matter less for short scripts. But if your script is going to grow to 100s of lines, you want a language with decent data structures, c & performance & it should be easy read. I used to use Go a lot but now I find V easier to use (I also use its REPL to test out simple things or as a calculator); though it is not as robust as Go.

To the OP: No matter what other languages you use, a good familiarity with /bin/sh is a must on Unix (or bash on Linux), as well as common unix tools which are often used in scripts. Most of the system scripts are in /bin/sh. One way to bootstrap quickly is to study them. To find them you can use find /bin /sbin /usr/bin /usr/sbin /libexec /usr/libexec -type f | xargs file | grep "POSIX shell". Pick short scripts and try to understand them thoroughly. You can also study scripts in /etc/rc.d/ and /etc/periodic/*/.
 
bakul said:
These things matter less for short scripts. But if your script is going to grow to 100s of lines, you want a language with decent data structures, c & performance & it should be easy read. I used to use Go a lot but now I find V easier to use (I also use its REPL to test out simple things or as a calculator); though it is not as robust as Go.
Click to expand...

The problem is that when you start a codebase you don't know how long it will be used and how large data pieces will be thrown at it and whether some constructs will be needed in the future that are not "shortcut" in the scripting language interpreter.

My favorite incident: I needed a street address soft matcher that would resolve typos. I used a scripting language and employed regular expressions for the matcher. That's nice because all these scripting languages use regular expression code in C and they are fast with that. So far so good, but suddenly I wanted to match addresses in a way that couldn't be expressed in a regex. I had to walk characters in strings manually one by one in the scripting language. Performance dropped a couple of orders of magnitudes.

Also note that Python has overall competent data structures, but they lump arrays and lists into one and do some magic behind the scenes. That makes it hard to explicitly force the data structure you know you need.
 
You must log in or register to reply here.
Back
Top