Solved Should I write all of my scripts in JavaScript?

  • Thread starter Deleted member 63539
  • Start date
Offtopic on: Thinbasic is a scripting language, not compiled language like other variants of basic.

BTW, I don't say I wanted to avoid shell at all. I know it's impossible. But I only want to use it the least possible. I have problems reading and understanding shell scripts.
Ok, I didn't know about it, I've never heard of Thinbasic.

However, back to your issue of parsing /etc/rc.d/ldconfig, I don't understand your statement "since my distro doesn't have /usr/local ".

Apart from the use of distro, what FreeBSD doesn't have /usr/local? It's been in there for, like, forever.
 
On Java, beside arguments on JSP and JVM, I have a feeling that it going completely replaced by PWA.

On the client side (i.e. Java applets running in a web browser), Java has never been widely used for 2 reasons: you had to download and install a JRE, and the first versions of Java were very heavy and slow.

This is why JavaScript development got so successful.

PWA are primarily targeting mobile devices and are probably not going to be very successful for 2 reasons: the lack of relevance/added value in most situations, and the development of WebAssembly.

WebAssembly is exactly the same thing as Java applets but pushed by Microsoft and Google. Their runtime being integrated into the web browser, they will not have the same fate as Java applets.

That said, Java is still widely used to develop micro-services and other scalable infrastructures on the server side.

Investment on Java for newcomers!?

As a hobbyist, it would make no sense.
But if you plan to make a comfortable living as a professional developer, it's a good idea.

If you want to become a professional developer in 2020, you have several options:

- If you have a good background in data science or AI, learn Python
- If you have a preference for server-side development, learn Java
- If you like user interface development, learn JavaScript/TypeScript and a framework such as VueJS or React

The demand is so high in those 3 areas that you'll never be unemployed.
 
However, back to your issue of parsing /etc/rc.d/ldconfig, I don't understand your statement "since my distro doesn't have /usr/local ".

Apart from the use of distro, what FreeBSD doesn't have /usr/local? It's been in there for, like, forever.

On a fresh FreeBSD system, created by ezjail (ezjail is my test environment), there is no /usr/local. Keep in mind I didn't have pkg installed and the ports tree, too, since I will replace them with ravensw and ravenports to create my own customized distro of FreeBSD. pkg installs into /usr/local but ravensw installs to /raven. I want ldconfig to include /raven/lib into it searth path, via the service /etc/rc.d/ldconfig that runs on every boot of the system, not by the environment variable LD_LIBRARY_PATH. My change will be global: removed /usr/local/sbin and /usr/local/bin from PATH completely but replace them with /raven/sbin and /raven/bin. So ask me to use a per user configuration like kpedersen said is not a solution for me.
 
kpedersen pkgsrc is the first thing I consider for my customized FreeBSD distro before I choose ravenports. Could you let me know how you could utilize it in the first place? As I know, it has broken on FreeBSD for a long time. It always failed at the bootstrap stage because of undefined reference error of libarchive when building pkg_create of the package pkg_install. They also acknowledge this problem, but their fix seemed to not working: https://pkgsrc.se/pkgtools/pkg_install
 
Shell is too hard for me. I'm porting a JavaScript interpreter could be run with #!/usr/bin/env js, it's written in C, it's small and fully support the ES2020 specification. The real value of it is it's a real interpreter, doesn't compile to C and relying on C compiler to compile and run the binary. That make it could be used like python and as a real scripting solution.

I come from Java, know a bit of C. I dislike JS, too. But if having to choose between shell and JS, I prefer JS. I like a full language that could be used as itself without relying on extra small utility with awful syntax like sed, awk to done the job. Yes, I know it's against the Unix philosophy. But I don't care about philosophy anyway.

On Windows, I used Thinbasic. Is there anything like that on Unix or we forced to stick with the Unix philosophy? I guess it's python.
Well, it depends on what you want to do.

The POSIX shell is well suited for small scripts. It’s good at creating pipes between commands and things like that (that’ll become difficult in JavaScript, I guess). Therefore it is used for typical system administration scripts, automating repetitive tasks and so on. It is not suitable for larger projects or generic programming.

As other people have noted, Python would be much better suited for more complex things. By the way, Python is a compiled language (although it can also be used interactively). The source code is compiled to a virtual machine byte code, quite similar to Java. In fact there is a project called „Jython“ that compiles Python source code to Java VM bytecode.

You say you know a bit of C, but at the same time you call awk’s syntax “awful”. Are you aware the awk is quite similar to C? In fact, awk’s main author was Brian Kernighan (who is still maintaining it!) who is also co-author of the C programming language. The letter K both in “K&R C” and “AWK” stands for Kernighan. Some people say that awk is just a scriptable version of C, with some restrictions and some enhancements (associative arrays, regular expressions). Many people underestimate the power of awk considerably, often abuse it for trivial things like cutting a column from a text file. By the way, awk is also compiled to intermediate byte code. Personally I regard awk to be positioned somewhere between the POSIX shell and Python, complexity-wise. I’ve written several scripts in pure awk (i.e. beginning with “#!/usr/bin/awk -f”).
 
You should look into awk(1) if you dislike writing if-then logic. Awk's expressiveness and power really shine when you use patterns even though they're considered "advanced" by some. Take the somewhat contrived example of counting shell usage by user, and paying special attention to root's shell:

Code:
#!/usr/bin/awk -f

# Set the field separator to ":". Default is whitespace
BEGIN { FS=":" }

# Skip comment lines
/^#/ { next }

# Capture root's shell
$1 ~ /root/ { rootShell=$7 }

# Keep shell usage counts
$7 != "" { shells[$7]++ }
$7 == "" { shells["No shell"]++ }

# Print results
END {
    print "Root's shell is", rootShell;
    for( i in shells ) {
            print i, shells[i];
    }
}

Sample run:
Code:
% ./shells.awk /etc/passwd
Root's shell is /bin/csh
No shell 1
/usr/local/libexec/uucp/uucico 1
/bin/csh 2
/usr/sbin/nologin 33

I find writing programs as a list of conditon -> action pairs fun and compelling.
Yes, awk(1) is somehow a mix of the spirits of the declarative & imperative programming paradigma.
Your script is errorneous: you have to look for UID 0, not only the name root. Usually we have only the toor user (sh(1) or bash(1) instead of csh(1)), but anyone is free to add any other name with UID 0.
 
  • Like
Reactions: a6h
You say you know a bit of C, but at the same time you call awk’s syntax “awful”. Are you aware the awk is quite similar to C? In fact, awk’s main author was Brian Kernighan (who is still maintaining it!) who is also co-author of the C programming language. The letter K both in “K&R C” and “AWK” stands for Kernighan. Some people say that awk is just a scriptable version of C, with some restrictions and some enhancements (associative arrays, regular expressions). Many people underestimate the power of awk considerably, often abuse it for trivial things like cutting a column from a text file. By the way, awk is also compiled to intermediate byte code. Personally I regard awk to be positioned somewhere between the POSIX shell and Python, complexity-wise. I’ve written several scripts in pure awk (i.e. beginning with “#!/usr/bin/awk -f”).
Well. Now I know the reason why people wrongly associated me with the troll. I admit I have never encountered awk nor did a quick research about it before posted this thread. It's my fault. I only encountered sed and I found people using sed like using magic. I'm afraid of it and as sed and awk usually compared together, I think awk should be on the same ship as sed: has an awful syntax. This turned out to be wrong. They are very different. From the tutorial it seemed to be familiar: https://www.tutorialspoint.com/awk/index.htm But from the code I saw people posted on many question answering sites, it still looks like magic for me. Perhaps because I didn't learn it so I don't understand what the script is doing so I found it cryptic.
 
This line suggests that you are not familiar with regular expression.
You are right. I could use functions to find and replace simple strings but never used such advanced find and replace technology.
 
Well. Now I know the reason why people wrongly associated me with the troll. I admit I have never encountered awk nor did a quick research about it before posted this thread. It's my fault. I only encountered sed and I found people using sed like using magic. I'm afraid of it and as sed and awk usually compared together, I think awk should be on the same ship as sed: has an awful syntax. This turned out to be wrong. They are very different. From the tutorial it seemed to be familiar: https://www.tutorialspoint.com/awk/index.htm But from the code I saw people posted on many question answering sites, it still looks like magic for me. Perhaps because I didn't learn it so I don't understand what the script is doing so I found it cryptic.
No one expects anyone to embrace languages in an instance. When I first started on unix I hated [g]awk & perl but after a while of forced usage and PRACTICE I'm quite proficient in the major script & parser languages of unix (though I rarely use perl these days). I've always like regexp & sed, though sometimes I can confuse myself with sed expressions I wrote years ago.:eek:

Pick one, eg sh, and learn it. In learning it you will come across the need for grep (regular expressions), loops in awk etc.
While Ollie@ did pooh-pooh how some people use awk and that's true , at least it's a starting point because awk is good at that.
 
Basically, AWK is fairly easy:
  1. initialization (BEGIN{...})
  2. function definitions
  3. process data & collect derived metadata:
  4. pattern1 action1
  5. pattern2 action2
  6. ...
  7. finalization (END{...}): usually print out derived metadata
The patterns can make use of regular expressions, which can get cryptic, but the basics are fairly easy, too. Any programmer (EDIT: and ambitious admin) should know at least the basics. Please RTFM re_format(7). I have a small paperback book on my desk: Tony Stubblebine: Regular Expression Pocket Reference, O'Reilly & Associates, Inc. (I have the german translation: Reguläre Ausdrücke kurz & gut)
 
  • Like
Reactions: a6h
Basically, AWK is fairly easy:
  1. initialization (BEGIN{...})
  2. function definitions
  3. process data & collect derived metadata:
  4. pattern1 action1
  5. pattern2 action2
  6. ...
  7. finalization (END{...}): usually print out derived metadata
And it should be emphasized that all of those 7 items are optional. For example, if you don’ need that pattern stuff, you can write an awk script that consists only of one BEGIN clause (with all of the code inside), and nothing else.
Code:
#!/usr/bin/awk -f
BEGIN {
        print "Hello World!"
}
 
You are right. I could use functions to find and replace simple strings but never used such advanced find and replace technology.
Regular expressions aren’t difficult to learn. I assume you already know wildcard patters that are used for filename matching (e.g. ls -l d*). Regular expressions work in a very similar way, the syntax is just a little different, and there are more things that you can do with them.
 
You are right. I could use functions to find and replace simple strings but never used such advanced find and replace technology.

Regular expressions appear in every good text editor, in awk, in lex, as C library, in every
respectable scripting language. Perhaps with small syntax differences, but everywhere
the same principle. If you learn them, you will avoid a lot of programming with simple
word. You are right that the syntax is awful, but it is absolutely not difficult to understand
them.
 
  • Like
Reactions: a6h
In some ways this is perhaps good. If someone suggests that we put Python in base, now we can turn around and say we already have Lua. Awk doesn't seem enough of a brand name.
Lua is also 99% as portable as C89+ (minus some integer assumptions) so there are certainly worse languages.

Unless the Linux kids break (g)awk, I would personally still recommend that. Lua is still too into its NPM / PIP dependencies (https://luarocks.org) to be maintainable in the long run.
 
Yes, better bad than worse. But there is always something worse, hence every bad thing is better.

The luanatics wants lua everywhere. If you want TeX and install texlive, you get luatex.

It is something like wayland. Although it has other functionality than X11, they want to substitute
X11 everywhere with it.

Is that only fanaticism?!
 
People have mentioned a lot of possible but unsuitable alternatives to shell scripting and wasted a bunch of time not answering your question. Use Python3. I suppose Perl used to be an option, but Python will be more useful elsewhere.

I'm glad you realized JS is not a good fit for this...

The suggestion to use TCL/TK for gui work wasn't terrible, but it is a bit esoteric.
 
[..] The suggestion to use TCL/TK for gui work wasn't terrible, but it is a bit esoteric.
Modern GUI scripting is done e.g. by QML + JavaScript. Using a declarative approach in this realm, as well as JavaScript's asynchronous behaviour, is very natural. But it's not well suited for CLI scripts.
 
In some ways this is perhaps good. If someone suggests that we put Python in base, now we can turn around and say we already have Lua. Awk doesn't seem enough of a brand name.
A little bit of background on the Lua story …

For ease of maintenance and flexibility, FreeBSD’s bootloader contains an embedded scripting language. For historical reasons, a Forth interpreter was used for that purpose – somewhat similar to the bootloader on Sun machines running SunOS / Solaris. The particular incarnation of Forth used by FreeBSD was called FICL. At the beginning (i.e. in the previous Century), that was a good thing, because FICL was very small and required very little RAM, so it could run within the low 640 KB of “realmode” memory and still have space for disk buffers and other things. Also, back in that time, quite a few developers were familiar with Forth because Sun Sparc machines were very common at Universities in those days.

However, things have changed. The pages of history have turned over to the 21th Century. Today, nobody knows Forth anymore, and it’s not really the typical beginners’ language. It’s error-prone and not easy to debug. And what’s worse, FICL was end-of-life and did not have a real maintainer anymore. Given that the bootloader is a critical component, the situation required a solution. There were several proposals at that time, including Python, but in the end the decision was to replace FICL with Lua. The reasons were quite similar: Lua is very compact and requires little memory, and it is easy to embed into a static binary. In fact that is the design goal of Lua. Also, it is an imperative language with a straight-forward syntax – So if you know any imperative language, you can easily learn Lua, too. Apart from that, it is actively maintained and used by many other projects as an embedded language for scripting and configuration purposes.

That’s how Lua got into FreeBSD.

By the way, once upon a time (again, in the previous Century), Perl was part of FreeBSD’s base system for quite a few years. But maintenance was a nightmare, so it had to go and live in the ports collection only. The Perl scripts that were used in the FreeBSD build process were rewritten in awk. The reason why awk was allowed to stay is that it is part of the POSIX standard, and it is relatively easy to maintain. So, the bourne shell and awk are the only scripting languages that remain in FreeBSD’s base system (Lua is only used for the bootloader, but it’s not part of the “userland”). Well, actually sed is a scripting language, too, but too restrictive to be counted as a generic programming language. Otherwise we would have to count sendmail, too (its .cf language is turing-complete).
 
Nobody has mentioned Rexx. I used it on zOS platform. Quick Freshport scanning reveals Rexx interpreter existence.
30 years ago, Rexx was the best scripting language around; the alternatives (/bin/sh, CLIST and DCL) were much worse. Perl and Tcl were just getting started and not broadly available, Python and Ruby and Lua and all the other modern ones not invented yet. In the early 90s, I used to write 1000-line scripts in Rexx on both VM and VMS (yes, on the Digital operating system!), because the only alternatives were FORTRAN and C and PL/1.

Today, we have much better choices.
 
30 years ago, Rexx was the best scripting language around

I really enjoyed it. My experience with it was PC-DOS and the 'E' editor. Rexx was possibly my first "programming language".

(Interestingly the implementation of Rexx on IBM's PC-DOS was one of the few implementations that was not actually done by IBM)
 
Back
Top