New angle: What can't I do with Bash?
I think I made a post before of "BASH projects" and the response was disappointing but the need is still there. So I'll guess I'll make a list and see if I can get a yes ,a no and some expanding on the subject.
I believe BASH can do a lot with Text files on a users computer but... 1. Can it automate a browser and turn it into a dataminer or something? Can bash use a programs API? 2. Can bash filter and sound an alert if certain Java script commands are made by a server? Are theses ambitions too tall? I'm mostly interested in what BASH can do as far as the internet is concerned. I would like to know the practical limitations of BASH. Any Scripts that you have written for a purpose would be of interests.Not the actual scripts , just the purpose. Thanks in advance |
Quote:
Quote:
Quote:
jlinkels |
SourceMage GNU Linux has this to say about its package management system, Sorcery:
Quote:
|
Moved: This thread is more suitable in Programming and has been moved accordingly to help your thread/question get the exposure it deserves.
|
the secret of unix kung fu is using the correct tool for the job.
carpenters generally don't turn up on site with just a screwdriver. (there's little point making life difficult). http://www.ariel.com.au/jokes/The_Ev...rogrammer.html |
Quote:
|
Well,
If you don't mind me putting in another 2¢ on this one: Quote:
Quote:
For #2, apart from actually running a sound-player with a specific file to play when a certain condition in the script has been reached, such as: Code:
if [ "$x" -eq "0" ]; Code:
...<snip>... HTH. |
Quote:
|
We use BASH because it is there. It has mass and takes up space.
Part of this is fueled by learning bits and pieces of Four Programming languages and Assuming that BASH is the most important for an Administrator Role. If I wish to be (Administrator Centered) when do I have to venture outside of BASH's abilities? What are BASH's abilities?
BASH just looks like an interface for applications that don't have one and a reusable one at that. If it runs in BASH it is using BASH as a terminal. BASH runs applications that are usually not part of it. I'm not going to look it up but the best description of BASH I received was that BASH is an application it's self which has helped my understanding of it immensely. So these non-stand alone applications run in BASH's environment which means that BASH is just mostly a environment for environment-less applications to run. BASH has control features and allows the output of one application to be the input of another. BASH also conveys the feedback of if the process was successful or not. So in a way BASH behaves as a configurable Operating System for Raw Applications that are not finished to STAND on their own. Am I wrong here? Is BASH Limited to what it will host as an application and behaves as an orchestra conductor? Would this assumption have been 100% percent correct with it's origial release but applications were purposely made for it to run? Now it is sort of both? As I grow as a user and accept CLI it looks more and more like a temporary fix or a problem that users don't want to accept ,maybe to experiment with or something you don't want to commit to. Having human readable files would be the only benefit. BASH looks experimental and makeshift which are admirable qualities! |
Quote:
|
I'll try to explain.
From what I can tell BASH started off as JUST an interpreter and over time became an interpreter that housed a few applications it's self so it's persona is that of something more than a lousy interpreter mainly because GUI's are not readily produced to remove it's need for utilities. I'm not trying to indiscriminatlely make a point to marginalize BASH ; (Edit) but BASH is just looking like a glamorized interpreter at this point.
|
Quote:
... It think you are approaching all this (administrator role) from a wrong end. It's like you are carefully studying a set of wrenches used to tune/fix an internal combustion engine not understanding how the engine works in the first place. ... For administrator role you better learn POSIX compliant (and limited) shells. I.e. don't count on all BASH features because nowadays not every system uses BASH as its default shell, e.g. look up "dash shell". |
Quote:
I think you are over-thinking a lot of what Bash is and does. Think about what any shell does as its root purpose, which is to invoke other processes in a way that a user can specify. This may be interactively, as with a keyboard, or through scripts stored in files. Everything else is just some add-ons to make it do its root job 'better'. The set of 'add-ons' includes a whole host of categories such as iteration, branching and other procedural logic, management of standard IO, text manipulation, creation and management of environment-based data structures, etc. As soon as your requirements for a task involve much or any of the things outside of Bash's (or any other shell) core competencies, then it probably shouldn't be a shell application. I would say that there are many cases where another programming language is better suited to jobs done strictly with Bash; even a few I've done myself. It is sometimes difficult to define what is a Bash application. If I wrap the invocation of Firefox in a bash script, is that application principally a shell script? What about if we call sed or grep instead of Firefox? In the end, it doesn't really matter. A common exercise in college computing courses is to write a shell. This forces the student to think about the purpose of a shell, and also forces the student to understand a bit about the Unix process model, and the concepts of standard IO. It is surprisingly easy to write a functional shell in a language like C, especially if you allow the use of ready-made components like the readline library. I suggest that you give it a try; you'll gain a lot of understanding. --- rod. |
Thanks for the Replies!
I really should have used the term CLI instead of environment. I use the term environment in a broader sense of the (Users Environment). A lot of my interpretation of BASH is from what Does Not happen when you open a BASH Application directly which is (nothing happens). I had a previous thread where it was discovered that most of BASH's ability is from controlling other separate applications that are not stored within BASH. This goes against the common belief of what defines BASH. Pick some BASH commands and chances are they are in /bin in a binary format. This is not BASH.BASH can find it and run it though.
The quoted paragraph is exaggerated to make a point of it being an understated concept. Quite often people will over emphasize a trivial concept that actually behaves as a negative by mentioning it. Why do they bother? So if I run a command which is in binary form sitting in /bin how does the user interact with it? CLI, and not GUI. So BASH in this broad sense is the users interactive environment for the command. How do I implement arguments? BASH.Thanks for dropping the (redline library) direction but I'm missing the point. When you state (shell) you really mean script correct,and you are not programming a interpreter you would be writing shell scripts? |
Quote:
And if I copy or symlink some_gui_app into /bin and run the app from there ? |
All times are GMT -5. The time now is 09:30 AM. |