Bash is the love of my life! I have been working for years on this problem now (not full-time of course), gradually moving in the direction of finally being able to challenge this:
"Inappropriate use
shell is the main domain specific language designed to manipulate the UNIX abstractions for data and logic, i.e. files and processes. ... Correspondingly, please be wary of writing scripts that deviate from these abstractions, and have significant data manipulation in the shell process itself. While flexible, shell is not designed as a general purpose language and becomes unwieldly when ... "
Another person has actually solved the most important show stopper already: http://ctypes.sh.
What now remains to be solved, are a few minor, additional details, and then simply writing a good manual of how to very successfully use bash as a general-purpose language.
My personal belief is that everything that you can do in other scripting languages, you can also do in Bash, only better.
IMO shell makes it very easy to work with multiple process (&). It's built in and natural.
>4) Performance
If you are carefull and know what you're doing, you can achive very good performance with the shell. Usually, better performance is achived processing less data, ie being inteligent. Rarely depends on the language (unless you care about cycle level performance, then yes :).
>6) Portability
I claim that it's way easier to depend on sh being on a (UNIX) system than $SCRIPTING_LANG.
Shell makes it easy to spawn multiple processes. It makes it reasonably easy to read those processes' standard out or standard error, though it's not that much fun to try to do both at the same time while keeping them distinct. [1]
It pretty much doesn't do anything else that you might want to do with multiple processes, though, and it tends to encourage multiple processes to communicate via text which is a problematic limitation that one often finds oneself "working around".
Shell is really powerful, but it hits a certain limit of what kind of tasks it can do and it hits that limit hard, and that's why when one imagines orchestrating many processes on a machine to do some task, to say nothing of orchestrating many processes on many machines, you don't see solutions based on shell, and indeed the very idea is laughable. Shell is best used by making sure it stays firmly restricted to the domain it shines in and not so much as trying to dip a toe into the spaces where it is not.
[1]: Note "not much fun" != "can't". Shell is fundamentally written around the idea that a process has one stream STDOUT that may go to other processes, and one stream STDERR which is generally intended to go to the console (or other user output like a log) no matter how complicated the pipeline. While you can get both streams and do things to them, you're starting to fight shell, which really wants to create pipelines with one "through" path with no branches out.
I think with the shell you have to adapt your abstractions to the "unix-way". For example, a queue to process will be a directory with N files, and each file can be processed in pararell by just something like "for f in dir/*; do process.sh "$f" & done;" but yeah ... it has limitations like everything.
With regards (3), my problem in shell is that it is very hard to spawn children without risking overloading the machine.
What I would like in bash is some easy way to limit the number of background processes I can spawn, and to just wait when I try to start another one until an existing one is finished.
Some simple jobs can be converted to use xargs -P, but for more complex things I end up having to do them without parallelisation, so I don't end up spawning 100s of background processes and bring my computer to it's knees.
Yes ... I think that should not be allowed (bring down the machine by a non-root user process). In Linux CPU_GROUPS/MEM_GROUPS can help, and the fair scheduler has improved the situation a bit from the old days where a fork bomb will bring the machine down.
But limiting the # of spawned children is possible using not so complicated ad-hoc solutions, but I guess it depends on the specific problem.
my personal belief is that anything one can do in bash i can do in sh. not sure if that's really true in practice, but that's my belief. i never use bashisms because i do not know what they are or how to use them.
In case you're not, here are some "Bashisms" that really suck to be without:
* built-in regex support (e.g. `[[ $var =~ ^1\.2\.[34]$ ]]`)
* process substitution (e.g. `diff <(before_command) <(after_command)`) and all sorts of other redirection tricks
* indexed and associative arrays
Some of this can be worked around by shelling off to grep for regular expression matching or awk for arrays, but Bash makes things so much cleaner and maintainable.
But once you adopt bash-only features, you're losing the main argument for a shell script: portable scripting without the need to first install something to get something else running. Once you require Bash, it's equally easy to demand Perl and that will provide a much richer scripting experience.
If you limit yourself to either a popular Linux distro or one of two Unixes/Unix-likes, then bash can be available out of the box. Just as C is not C++, shell is not bash, so a shell script is what runs on (d)ash, busybox, toybox, ksh, bash, zsh, etc., without modifications. If it requires bash or zsh, then it's not a shell script but a bash/zsh/fish script. To name a popular non-Linux OS, take a fresh FreeBSD or OpenBSD install. No bash to be found, unless installed via ports and rightfully so. That said, I use bash myself all the time as an interactive shell but /bin/sh is not bash. sh (including bash and zsh) are terribly hard to write correct and resilient scripts in, and even rc is much saner to script in.
> To name a popular non-Linux OS, take a fresh FreeBSD or OpenBSD install. No bash to be found, unless installed via ports and rightfully so.
And even if you do install it, it still won't work with scripts that specify /bin/bash (which is a lot of them, thanks to sloppy tutorials), since it will be in /usr/local/bin and not /bin.
I'm having trouble remembering the last time I saw a BSD box during my work day, unless Juniper gear counts. No knock against BSD but seriously how many people are writing POSIX shell scripts because they need their shell scripts to work with Linux, QNX and BSD?
A few, but there are still cases where it's best to stick with the plain old Bourne shell syntax.
When I mentioned embedded systems I primarily thought of Linux/Busybox-based devices, like OpenWRT. While one surely can have bash there, usually base image doesn't contain it.
Same story about the most common Linux-based OS out there: Android. And, while it's no one manually runs shell scripts there, apps quite frequently exec() things, so shell scripting still matters there - a tiny bit. Also, shell scripting is heavily used in firmware upgrades/patches, as well as a glue for the root/unlocking hacks.
If you plan to write a redistributable component or an useful hack for such platforms, you'd best stick with a very limited subset of POSIX.
Effective bash programming involves invoking other Unix commands. That's what the shell is for, after all. I don't know off the top of my head what you'd use for matrix multiplication; I guess it depends.
For another example, jq and jshon are excellent tools for querying, transforming, or creating JSON values.
My experience is that programming by composing Unix programs that communicate via pipes and files can be very pleasant and productive.
Sometimes I lament aspects of bash syntax and semantics, but it's also much more convenient than other scripting languages for tasks related to spawning programs and pipelines and working with files.
One of my recent projects that I've been having a lot of fun with is a kind of continuous integration system built mostly with bash scripts. It involves a lot of calls to git and Docker, process manipulation, file descriptor redirection, and file system manipulation—and bash makes all this pretty easy and concise.
We already have good alternatives to these things. My financial life runs entirely in bitcoin, except for the shrinking list of payees who are still allowed to request payment in fiat money. Of course, I had to move out, live elsewhere, and continue trading from there, to make it happen. But then again, everything is so much cheaper here ...
The presence of honey attracts bees, the presence of horse shit attracts flies, the presence of sheep attracts wolves, and the presence of manipulable people attracts manipulators.
If these people started visiting another part of the web, "Ad Tech" would immediately re-emerge there too. The tigers just follow the herds of wild buffalos.
So, yes, watch out, if you can see wild buffalos, that means indeed that the tigers cannot be far away.
The article wants to jeopardize the god-given right of some of the manipulators to manipulate the manipulable crowds.
"Ad dollars are being stolen from publishers who actually put in an effort to create original, useful content. This is very wrong."
Ha ha ha hah ha!
Apparently, there are legitimate and illegitimate manipulators. The good and the bad thieves! The good and the bad burglars!
They are in a daggers-drawn contest on who exactly has the right to rip off the idiots!
Yes, good question, who is the one who legitimately "owns" these idiots?
For a starters, in any discriminatable situation, I do not show pictures of myself.
That is indeed one reason on a long list, why I only work online. I simply do not accept job offers or service contracts in which I would have to disclose racial information.
Generally, if the counterparty decides to proceed, and then breaks our contract on impermissible grounds, they will obviously be facing a bill for the damage, as specified in the T & C of the marketplace in which we execute the trade. In those cases, we do not discuss. We repossess and confiscate only.
Fundamentally, I believe that anybody has the right to be as racist as he wants and towards any race of his own choosing. That is certainly not the problem.
I only demand that the third party who will be the judge of it, must be color blind, objective, and impartial. That is one reason on the list of so many, why I never agree to any part of any state apparatus to be the judge of such situation.
I am personally not racist. That would be utterly contrary to my fundamental beliefs. In the Farewell Sermon, delivered after the final double recitation, as narrated by Ibn Hanbal, you can find my fundamental belief about racism:
Indeed, there is no superiority of an Arab over a non-Arab, nor of a non-Arab over an Arab, nor of a white over a black, nor a black over a white, except for his greater obedience to the laws of God and his good works.
> Why do people have problems with taxes? I don't. Never have.
Fine. However, that is a personal decision of yours. Other people make other decisions.
> When taxes build schools and infrastructure and provide policing and social support it's a good thing. When taxes are misused (military industrial complex perhaps) that's an issue with the system of government, not taxes.
Why not do it with sandwiches? The government collects 500 dollars from you in taxes and gives a 5-dollar sandwich in return. From now on, taxes are necessary, because how else would we get hold of sandwiches?
> I do have an issue with the wealthiest people sheltering their money from taxation.
If it were your money, I would understand. It isn't your money. You insist that other people should make decisions as you like them to. Why? And why not the other way around?
> But you are left with A LOT MORE money after taxes. And this is the issue for me.
Again, it is not YOUR money. It is THEIRS. You cannot impose your opinion of what is right and wrong onto others. I could perfectly do the same, and insist that you must adopt MY views on right and wrong.
You could say that your view is backed by government violence, but as you know, violence is not something particularly complex to orchestrate. In fact, it is trivially easily matched. Nowadays we have got people incessantly bombing other people exactly over this kind of problems. Your desire to impose your beliefs onto others, will inevitably turn out to be very costly, because people like you are doing that in too many areas and to too many people.
Ultimately, what you believe to be right or wrong will no longer matter. Sooner or later, it will only be what you are willing to risk your life and die for that will matter.
Imagine person A invoices person B for services delivered. In such case, it is always possible to get A invoice C and then C invoice B. C would just be a middleman. There is nothing wrong with that.
Then, you could easily "chainify" the concept: A -> C1 -> C2 -> C3 -> B
Now you turn C1 into a reservoir. It does not pay out to A, because A prefers to save his revenue inside C1. Therefore, A never gets taxed on income that remains in C1.
Also, whenever reasonable, C2 and C3 pay for A's spending. That money does not hit A either, and not even C1. Therefore, A actually needs little actual money to be paid out to him. His expenses are taken care of by C2,C3, ..., while his savings are held up in the C1 reservoir.
Even though B could pay millions for A's services, in terms of taxation, A makes almost no money at all. The money remains legally stuck in the C chain. Even though A is a real person, the C chain is not. It is a chain of virtual persons: "incorporations". They used to exist only on paper. These days they only exist on a computer screen.
Moving nodes in the chain to another state or to countries, pretty much amounts to just updating a field in a database. Depending on what you fill out in that database field, you pay more or less tax. Hence, the reason why they consistently fill out the cheapest choices on the screen.
In other words, there is never a valid reason to pay income tax for a "chainified" income stream. Therefore, income tax is in reality not a tax on income but on the inability to "chainify" income.
In technology, programming work is about looking up, composing, and debugging code. I yet have to meet one person who learned it at school.
In the school environment, the emphasis is, has always been, and will always be, to repeat things from memory.
If the IT teacher were good at looking up, composing, and debugging, and given the kind of salaries you that get when you are good at that, he would not be teaching. He would seek to multiply his income often ten times by actually doing it, instead of teaching it.
In fact, you can only learn from people who are doing it themselves. Everybody else does not really know how to do it.
Therefore, the teacher is only good at what will give you beautiful credentials: repeating from memory. That is also what he will seek to perpetuate with his own students.
Formal education does not only NOT fix poverty. Formal education actively creates it. Instead of spending your formative years learning the skill that will make you gain income, you learn to repeat from memory. There is not one industry where this would be of value.
You need to be able to produce things of value, just to survive. It is exceedingly dangerous to spend all your time on things that will never produce any value at all.
I am non-American mixed-race. I personally consider racism to be -- in and of itself -- a non-issue. It does not kill you, and everything that does not kill you, ultimately makes you stronger.
I consider racism to be irrelevant because it mostly is. I can barely imagine a new situation in which someone would be able to stage a racist attack. I am probably entirely hedged against those already.
The real problem is always the abuse of government power: "I’ve been interrogated at gunpoint by police because I fit the description".
So, yes, if they choose the time and the place, they can indeed attack you, if they so desire. However, it perfectly well works the other around as well. If you chose the time and the place, it would work too. The only solution that truly works against the problem of lack of respect, is to inflict respect-instilling reprisals.
Therefore, the real problem, are your false beliefs in their fake legitimacy. Hence, in reality, state racism is a problem of religion.
Racism against Muslims pretty much fails, because they are increasingly making that very practice insanely dangerous. The police are very aware of that. They know that there will routinely be reprisals. This is the enormous attraction of Islam. It pretty much solves all the problems of abuse of power, including state racism.
Well, since software engineering is a field where the government is not able to settle the matter just by slapping the obligation to have a particular degree or certification just to be admitted to the job, employers are allowed to choose. If you have an aptitude for programming, you will be better off just programming for 4 years. Going to college and reading books about programming will turn out to be only marginally useful, and actually quite costly. Instead of learning, and making quite good money, you will be digging yourself into a debt hole, while you will still need to pick up the real skills afterwards, at the expense of an ever more skeptical employer.
bcwallet is a cli with an interactive user interface. I never use a cli program that possibly could start waiting for user input. It could cause a "halting problem" in the script that incorporates it. That is literally a show stopper. Waiting for user input in a commandline script, is bug. It is not a feature. That bcwallet thing is simply full of bugs.
Browsers and things like that are valid interactive user interfaces. The cli/shell mostly exists to test stuff so that you can add it to a script, which you can add again to another script, ad nauseam ;-)
The actually interesting part in all of this has been done by bitmerchant.
Unfortunately, bitmerchant has no simple cli program attached. You need to deal with python instead, even if you have nothing to do with python. That is also a show stopper. Please, also learn haskell, ocaml, perl, lua, and two other undecisive motherfuckers, just because you want to incorporate one or two cli actions written in another scripting vernacular, into your own script.
I don't want to know in what it was written. If I cannot ignore in what it was written, I will probably avoid using it.
So, we almost had a functioning solution.
Of course, a simple man page would have been phanthastick.
But ok, we are not going to incessantly demand that people work for free! ;-)
"Inappropriate use
shell is the main domain specific language designed to manipulate the UNIX abstractions for data and logic, i.e. files and processes. ... Correspondingly, please be wary of writing scripts that deviate from these abstractions, and have significant data manipulation in the shell process itself. While flexible, shell is not designed as a general purpose language and becomes unwieldly when ... "
Another person has actually solved the most important show stopper already: http://ctypes.sh.
What now remains to be solved, are a few minor, additional details, and then simply writing a good manual of how to very successfully use bash as a general-purpose language.
My personal belief is that everything that you can do in other scripting languages, you can also do in Bash, only better.