Re: Bash usage: was implicit linkage
On Mon, Oct 13, 2014 at 02:10:11PM +0900, Joel Rees wrote: Which is another way of saying that you want others to have already made the mistakes for you. No it isn't! Ponder why most people take their car to a mechanic for servicing. And you snipped: As long as you recognize that somebody has to make the mistakes, and don't mind watching and learning while they do, that's not necessarily a bad thing, given courtesy and quid-pro-quo, of course. Not on purpose. I didn't see it. It wasn't near that paragraph. Paying a mechanic is one kind of quid-pro-quo, wouldn't you say? Don't know about you, but I don't know anyone who pays their mechanic to make mistakes. Au contraire in fact. Do I need to unpack that a bit more, talk about how testing is a substitute for making mistakes? No thanks. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141013135359.GC2362@tal
Re: Bash usage: was implicit linkage
On Mon, Oct 13, 2014 at 10:53 PM, Chris Bannister cbannis...@slingshot.co.nz wrote: On Mon, Oct 13, 2014 at 02:10:11PM +0900, Joel Rees wrote: Which is another way of saying that you want others to have already made the mistakes for you. No it isn't! Ponder why most people take their car to a mechanic for servicing. And you snipped: As long as you recognize that somebody has to make the mistakes, and don't mind watching and learning while they do, that's not necessarily a bad thing, given courtesy and quid-pro-quo, of course. Not on purpose. I didn't see it. It wasn't near that paragraph. Paying a mechanic is one kind of quid-pro-quo, wouldn't you say? Don't know about you, but I don't know anyone who pays their mechanic to make mistakes. Au contraire in fact. Do I need to unpack that a bit more, talk about how testing is a substitute for making mistakes? No thanks. And yet it is apparent that you need it unpacked for you. Good mechanics made plenty of mistakes while learning the trade, and learned from their mistakes. That's what schools are for, and that's why those who learn on the job practice on junkers and their own hot-rods before they tackle customers' cars. Tests at school are one more opportunity to make sure that most of the learning by mistakes is behind you when you start working on customer equipment. (I don't want the straight-A student right out of school as my mechanic, or doctor. Straight-A students make their mistakes on the job.) -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOWKjMpdQCei65i-CuECnSXoDZyRWEnfs1Mhtz2ZZ0y=g...@mail.gmail.com
Re: Bash usage: was implicit linkage
On 12/10/14 04:12, Peter Zoeller wrote: But the nice thing is shell scripting is simplistic easy to learn and understand. I refer the audience to David A. Wheeler's essay[1] on how to handle filenames correctly in shell scripts, and to the bug report that he filed against POSIX.1-2008[2] on the subject. From those, I take away the lesson that no, shell scripting is not simplistic, easy to learn, and easy to understand. It just *looks* simplistic, easy to learn, and easy to understand, in ways that make it a horribly effective footgun. [1] http://www.dwheeler.com/essays/filenames-in-shell.html [2] http://austingroupbugs.net/view.php?id=248 - If the people who curate the standard commit these kinds of errors when writing examples for the standard, what hope does J. Random User have? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543a3ce7.5000...@zen.co.uk
Re: Bash usage: was implicit linkage
On Sb, 11 oct 14, 21:40:49, Steve Litt wrote: From my viewpoint, shellscripts were never intended to be big, huge programs. To me, they just glue together commands, and have a few rudimentary branching and looping constructs. Isn't that like buying IKEA furniture, but when you get home you realise all those little plastic bags with screws and mounting pieces are missing? I will say this: Any program that requires additional scripting just to get it running is insufficiently advanced. (you can quote me on that) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Bash usage: was implicit linkage
On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote: On Sb, 11 oct 14, 21:40:49, Steve Litt wrote: From my viewpoint, shellscripts were never intended to be big, huge programs. To me, they just glue together commands, and have a few rudimentary branching and looping constructs. Isn't that like buying IKEA furniture, but when you get home you realise all those little plastic bags with screws and mounting pieces are missing? I will say this: Except that A: different glue (screws and mounting pieces) may be required for different environments where you would use the furniture; B: there's no practical way to predict all possible environments where someone might want to use it, or to provide the necessary glue for all of those unpredicted environments; C: there's a lot more room for individual flexibility in shell scripts, et cetera, than there is in furniture assembly hardware; and D: in many / most cases, the glue is already provided for you (either by upstream or by some middleman) by the time the furniture reaches you to begin with. In addition, I understood the comment you're responding to as being about shell scripts as an overall idea, rather than about their usage in any particular context. It's entirely possible for the needed scripts to have been written by upstream, just as it would be possible for logic in other languages to have been written by upstream. All that comment seems to say is that shell scripts are specifically intended as the glue to let you stick together existing components *in whatever way you happen to want*, as opposed to being intended as a building block for contructing such components. If you don't need to stick the components together because they're fine on their own (e.g., grep is useful without any shell constructs), that's OK; if you want to stick the components together using something else, that's fine too; but if you want to stick them together, shell scripts are one tool you have with which to do so. Any program that requires additional scripting just to get it running is insufficiently advanced. (you can quote me on that) Part of the tradeoff for power is responsibility - both in the responsibility to use the power wisely, and in the responsibility to do things yourself rather than have others do them for you. If you don't want the responsibility of writing shell scripts (or other scripting), you will have to accept not having the power to do some of the things you could do with such scripts. If you don't want that power either, that's fine for you - but others may not feel the same way. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bash usage: was implicit linkage
On Du, 12 oct 14, 10:30:52, The Wanderer wrote: On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote: Any program that requires additional scripting just to get it running is insufficiently advanced. (you can quote me on that) Part of the tradeoff for power is responsibility - both in the responsibility to use the power wisely, and in the responsibility to do things yourself rather than have others do them for you. But I'm also aware of the limits of my powers and don't try to do too much, but instead use the right tool. If you don't want the responsibility of writing shell scripts (or other scripting), you will have to accept not having the power to do some of the things you could do with such scripts. As well as avoid some of the mistakes I would (most probably) do. If you don't want that power either, that's fine for you - but others may not feel the same way. And I'm fine with that. It's just that others seem to think that simply because Debian is using a specific tool by default it will suddenly discard the alternatives. This is not how Debian works. As long as there will be people available to do the work in maintaining the alternatives they will have their place in Debian, just like file-rc, runit, etc. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Bash usage: was implicit linkage
On Sun, 12 Oct 2014 09:33:43 +0100 Martin Read zen75...@zen.co.uk wrote: On 12/10/14 04:12, Peter Zoeller wrote: But the nice thing is shell scripting is simplistic easy to learn and understand. I refer the audience to David A. Wheeler's essay[1] on how to handle filenames correctly in shell scripts, and to the bug report that he filed against POSIX.1-2008[2] on the subject. From those, I take away the lesson that no, shell scripting is not simplistic, easy to learn, and easy to understand. It just *looks* simplistic, easy to learn, and easy to understand, in ways that make it a horribly effective footgun. [1] http://www.dwheeler.com/essays/filenames-in-shell.html Martin, Thanks so much for the preceding resource. It's worth its weight in gold, and I've bookmarked it for quick retrieval. This essay practically screams out for somebody to write a C program that takes an argument of an arbitrary string, finds all files in a directory, and returns a long string with those files separated by the arbitrary string. A shellscript can then use mktemp or some other facility to make that arbitrary string, pass it to the C program, and then use the temporary string as a sure fire field separator. The C program could also take an option as to whether or not should find hidden files, and it could prepend ./ onto all relative paths not already beginning with ./. I might do that tonight. Thanks for this great info. I wish I'd had it a decade ago. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012134204.37901...@mydesq2.domain.cxm
Re: Bash usage: was implicit linkage
On 10/12/2014 at 01:42 PM, Steve Litt wrote: On Sun, 12 Oct 2014 09:33:43 +0100 Martin Read zen75...@zen.co.uk wrote: On 12/10/14 04:12, Peter Zoeller wrote: But the nice thing is shell scripting is simplistic easy to learn and understand. I refer the audience to David A. Wheeler's essay[1] on how to handle filenames correctly in shell scripts, and to the bug report that he filed against POSIX.1-2008[2] on the subject. From those, I take away the lesson that no, shell scripting is not simplistic, easy to learn, and easy to understand. It just *looks* simplistic, easy to learn, and easy to understand, in ways that make it a horribly effective footgun. [1] http://www.dwheeler.com/essays/filenames-in-shell.html Martin, Thanks so much for the preceding resource. It's worth its weight in gold, and I've bookmarked it for quick retrieval. This essay practically screams out for somebody to write a C program that takes an argument of an arbitrary string, finds all files in a directory, and returns a long string with those files separated by the arbitrary string. How would you handle the case where the arbitrary string appears in one or more of the filenames? The usual approach is by escaping, which is easy enough with a single character, but offhand I don't see any potentially robust way to do escaping of an arbitrary string in such a way that the result would be necessarily clear to the calling shell script. At the very least you'd probably need an escape syntax complicated enough to obviate most of the advantages of not needing to handle filename parsing directly in shell code... -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bash usage: was implicit linkage
On Sun, 12 Oct 2014, Steve Litt wrote: This essay practically screams out for somebody to write a C program that takes an argument of an arbitrary string, finds all files in a directory, and returns a long string with those files separated by the arbitrary string. You seem to be looking for find -print0; \0 is one of the few characters which is not valid to have in a file name. It's not like it's that hard to do this properly in a policy compliant POSIX shell, either. Use IFS and reset it as appropriate, or properly quote things. -- Don Armstrong http://www.donarmstrong.com Il semble que la perfection soit atteinte non quand il n'y a plus rien a ajouter, mais quand il n'y a plus rien a retrancher. (Perfection is apparently not achieved when nothing more can be added, but when nothing else can be removed.) -- Antoine de Saint-Exupe'ry, Terres des Hommes -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012181654.gx23...@teltox.donarmstrong.com
Re: Bash usage: was implicit linkage
Andrei POPESCU wrote: On Sb, 11 oct 14, 21:40:49, Steve Litt wrote: From my viewpoint, shellscripts were never intended to be big, huge programs. To me, they just glue together commands, and have a few rudimentary branching and looping constructs. Isn't that like buying IKEA furniture, but when you get home you realise all those little plastic bags with screws and mounting pieces are missing? I will say this: Any program that requires additional scripting just to get it running is insufficiently advanced. (you can quote me on that) Maybe if you're in a desktop environment. If you're managing servers and services, one tends to wire together multiple services, often in environment-specific ways - and it's very common to write glue scripts. Seems to me that a big part of the issue is increasing use of Debian (and Linux in general) on the desktop. It seems like desktop support is driving more and more design decisions. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543ac7c6.4090...@meetinghouse.net
Re: Bash usage: was implicit linkage
On Sun, 12 Oct 2014 17:07:01 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: On Sb, 11 oct 14, 21:40:49, Steve Litt wrote: From my viewpoint, shellscripts were never intended to be big, huge programs. To me, they just glue together commands, and have a few rudimentary branching and looping constructs. Isn't that like buying IKEA furniture, Exactly! but when you get home you realise all those little plastic bags with screws and mounting pieces are missing? Not similar, becase either the parts are there, or they're creatable with a few very basic tools (much easier to create files than screws). I will say this: Any program that requires additional scripting just to get it running is insufficiently advanced. (you can quote me on that) I can't argue with the preceding, because it's a belief, no more or less valid than my (very contradictory) belief. The best I could do is create a run script making program that asks you a few questions and writes the script for you. Which, if it would bring more people into the daemontools fold, isn't a half bad idea. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012143419.10361...@mydesq2.domain.cxm
Re: Bash usage: was implicit linkage
Don Armstrong d...@debian.org writes: On Sun, 12 Oct 2014, Steve Litt wrote: This essay practically screams out for somebody to write a C program that takes an argument of an arbitrary string, finds all files in a directory, and returns a long string with those files separated by the arbitrary string. You seem to be looking for find -print0; \0 is one of the few characters which is not valid to have in a file name. Sadly POSIX has no -print0 for find[1]. So if you are for some reason limited to POSIX, there is no nice solution. It's not like it's that hard to do this properly in a policy compliant POSIX shell, either. Use IFS and reset it as appropriate, or properly quote things. It's possible, but prone to errors. Ansgar [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85oatht9ci@tsukuyomi.43-1.org
Re: Bash usage: was implicit linkage
On Sun, 12 Oct 2014 11:16:54 -0700 Don Armstrong d...@debian.org wrote: On Sun, 12 Oct 2014, Steve Litt wrote: This essay practically screams out for somebody to write a C program that takes an argument of an arbitrary string, finds all files in a directory, and returns a long string with those files separated by the arbitrary string. You seem to be looking for find -print0; \0 is one of the few characters which is not valid to have in a file name. Let me think about that. I wasn't aware that \0 couldn't get into a filename. I was concerned about the following in /http://www.dwheeler.com/essays/filenames-in-shell.html : = Most shells cannot store byte 0 in a variable at all. You can’t even pass such null-separated lists back to the shell via command substitution; cat $(find . -print0) and similar “for” loops don’t work. Even the POSIX standard’s version of “read” can’t use \0 as the separator (POSIX’s read has the -r option, but not bash’s -d option). = It's not like it's that hard to do this properly in a policy compliant POSIX shell, either. Use IFS and reset it as appropriate, or properly quote things. I'll try these things, before writing my own return each filename program. Thanks. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012150633.0dc9e...@mydesq2.domain.cxm
Re: Bash usage: was implicit linkage
2014/10/12 23:07 Andrei POPESCU andreimpope...@gmail.com: On Sb, 11 oct 14, 21:40:49, Steve Litt wrote: From my viewpoint, shellscripts were never intended to be big, huge programs. To me, they just glue together commands, and have a few rudimentary branching and looping constructs. Isn't that like buying IKEA furniture, but when you get home you realise all those little plastic bags with screws and mounting pieces are missing? I will say this: Any program that requires additional scripting just to get it running is insufficiently advanced. s/advanced/customized/ Or you could talk about the difference between the jobs of distributor and integrator, if you're completely anti-DIY. [...] Although, some of us don't really care all that much for IKEA furniture. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Bash usage: was implicit linkage
2014/10/13 2:14 Andrei POPESCU andreimpope...@gmail.com: On Du, 12 oct 14, 10:30:52, The Wanderer wrote: On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote: Any program that requires additional scripting just to get it running is insufficiently advanced. (you can quote me on that) Part of the tradeoff for power is responsibility - both in the responsibility to use the power wisely, and in the responsibility to do things yourself rather than have others do them for you. But I'm also aware of the limits of my powers and don't try to do too much, but instead use the right tool. Let's gloss over the idea that opinions on what constitutes the right tool differ, and ignore the question of what to do when the right tool doesn't exist. If you don't want the responsibility of writing shell scripts (or other scripting), you will have to accept not having the power to do some of the things you could do with such scripts. As well as avoid some of the mistakes I would (most probably) do. Which is another way of saying that you want others to have already made the mistakes for you. As long as you recognize that somebody has to make the mistakes, and don't mind watching and learning while they do, that's not necessarily a bad thing, given courtesy and quid-pro-quo, of course. [...] Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Bash usage: was implicit linkage
2014/10/13 2:45 Steve Litt sl...@troubleshooters.com: On Sun, 12 Oct 2014 09:33:43 +0100 Martin Read zen75...@zen.co.uk wrote: On 12/10/14 04:12, Peter Zoeller wrote: But the nice thing is shell scripting is simplistic easy to learn and understand. I refer the audience to David A. Wheeler's essay[1] on how to handle filenames correctly in shell scripts, and to the bug report that he filed against POSIX.1-2008[2] on the subject. From those, I take away the lesson that no, shell scripting is not simplistic, easy to learn, and easy to understand. It just *looks* simplistic, easy to learn, and easy to understand, in ways that make it a horribly effective footgun. [1] http://www.dwheeler.com/essays/filenames-in-shell.html Martin, Thanks so much for the preceding resource. It's worth its weight in gold, and I've bookmarked it for quick retrieval. mutter mutter ... cleaning input ... tool ... quick hack belt ... generalized tool box mutter mutter This essay practically screams out for somebody to write a C program that takes an argument of an arbitrary string, finds all files in a directory, and returns a long string with those files separated by the arbitrary string. A shellscript can then use mktemp or some other facility to make that arbitrary string, pass it to the C program, and then use the temporary string as a sure fire field separator. The C program could also take an option as to whether or not should find hidden files, and it could prepend ./ onto all relative paths not already beginning with ./. I might do that tonight. mutter mutter ... RE ... glob ... sed - awk wars ... perl ... python - ruby ... mutter mutter erk cough cough man xargs mutter mutter
Re: Bash usage: was implicit linkage
On Mon, Oct 13, 2014 at 07:53:03AM +0900, Joel Rees wrote: 2014/10/13 2:14 Andrei POPESCU andreimpope...@gmail.com: On Du, 12 oct 14, 10:30:52, The Wanderer wrote: On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote: Any program that requires additional scripting just to get it running is insufficiently advanced. (you can quote me on that) Part of the tradeoff for power is responsibility - both in the responsibility to use the power wisely, and in the responsibility to do things yourself rather than have others do them for you. But I'm also aware of the limits of my powers and don't try to do too much, but instead use the right tool. Let's gloss over the idea that opinions on what constitutes the right tool differ, and ignore the question of what to do when the right tool doesn't exist. If you don't want the responsibility of writing shell scripts (or other scripting), you will have to accept not having the power to do some of the things you could do with such scripts. As well as avoid some of the mistakes I would (most probably) do. Which is another way of saying that you want others to have already made the mistakes for you. No it isn't! Ponder why most people take their car to a mechanic for servicing. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141013043828.GJ22545@tal
Re: Bash usage: was implicit linkage
On Mon, Oct 13, 2014 at 1:38 PM, Chris Bannister cbannis...@slingshot.co.nz wrote: On Mon, Oct 13, 2014 at 07:53:03AM +0900, Joel Rees wrote: 2014/10/13 2:14 Andrei POPESCU andreimpope...@gmail.com: On Du, 12 oct 14, 10:30:52, The Wanderer wrote: On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote: Any program that requires additional scripting just to get it running is insufficiently advanced. (you can quote me on that) Part of the tradeoff for power is responsibility - both in the responsibility to use the power wisely, and in the responsibility to do things yourself rather than have others do them for you. But I'm also aware of the limits of my powers and don't try to do too much, but instead use the right tool. Let's gloss over the idea that opinions on what constitutes the right tool differ, and ignore the question of what to do when the right tool doesn't exist. If you don't want the responsibility of writing shell scripts (or other scripting), you will have to accept not having the power to do some of the things you could do with such scripts. As well as avoid some of the mistakes I would (most probably) do. Which is another way of saying that you want others to have already made the mistakes for you. No it isn't! Ponder why most people take their car to a mechanic for servicing. And you snipped: As long as you recognize that somebody has to make the mistakes, and don't mind watching and learning while they do, that's not necessarily a bad thing, given courtesy and quid-pro-quo, of course. Paying a mechanic is one kind of quid-pro-quo, wouldn't you say? Paying money to buy the car is another form of quid-pro-quo, as well, I'd say. Do I need to unpack that a bit more, talk about how testing is a substitute for making mistakes? -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43io+hd6vbnnjmvetz-nnt9ernukfb6fdrkdqqz3fvrq...@mail.gmail.com
Bash usage: was implicit linkage
On Sat, 11 Oct 2014 19:05:19 -0400 Doug dmcgarr...@optonline.net wrote: On 10/11/2014 05:28 PM, Steve Litt wrote: On Sat, 11 Oct 2014 21:21:14 +0300 Daemontools runscripts are incredibly simple shellscripts, that I'm sure you could write no sweat except in very wierd edge cases. Here's my run script for my home-grown cron substitute: == #!/bin/sh ### DON'T START littcrond UNTIL THE NETWORK'S UP ### pingaddr=8.8.8.8 pingaddr=192.168.100.96 echo littcrond checking network 12 while ! ping -q -c1 $pingaddr /dev/null; do sleep 1 echo littcrond REchecking network 12 done ### RUN THE DAEMON ### exec envuidgid slitt envdir ./env setuidgid slitt \ /d/at/python/littcron/littcron.py \ /d/at/python/littcron/crontab == The last three lines are really one line that wordwraps in email. If I hadn't checked for the network being up, this would have been a two line shellscript. I've known you (online) for several months, and although we sometimes disagree, I know you're pretty smart, so I'm positive you could have written this shellscript without breaking a sweat. /snip/ I've been using Linux seriously for about five years, altho I diddled around with it a bit earlier. About the time I started seriously using it, I took a course in Linux at the local community college, of which perhaps a third was devoted to scripting. Quite some time earlier, I had taken a course in Pascal, which I did very well in, and I actually wrote some useful code in that language for my job as an engineer. Prior to that, I used and wrote a lot of stuff in BASIC. Getting back to my Linux class, I received a B+. I don't know how much code I could have actually written when class was over, since one needs to know a lot more about system commands. At any rate, it's been about five years, and I could not now write the script you use to illustrate this message, and I'm not really sure I can read it! BASH scripts are written in perfectly logical code, quite similar, in fact, to Pascal. The problem is that they don't have the advantage of normal language; they rely on all sorts of abbreviations instead of the English words that more popular programming languages like Pascal, C, Python, and BASIC use. It's been probably 25 years since I wrote anything in Pascal or BASIC, but with about 30 minutes of reference-book research, I think I could go back and do it now. I can't imagine that to be true with BASH scripting. Just call me dufus. --doug Hi Doug, You're absolutely right. From my viewpoint, shellscripts were never intended to be big, huge programs. To me, they just glue together commands, and have a few rudimentary branching and looping constructs. Their loops are incredibly slow, you'd *never* do an inner loop in Bash. To me, if something involves you doing your own logic rather than calling other executables to do it, then Python, C, or some other real language is the way to do it. So yes, sysvinit startup scripts are on the far edge of what Bash should be used for. I'd say most daemontools run scripts are under 20 lines of code, so you'll be able to re-figure them, in a few minutes, six months from now. Now that I've said that, you can accomplish some pretty incredible things by gluing a few commands together. I wrote the better half of a http log evaluation program using a shellscript gluing together grep, cut, and awk, and piped the remainder (which was a much smaller data set than what went in) to a Python program or something like that. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011214049.0a4dd...@mydesq2.domain.cxm
Re: Bash usage: was implicit linkage
On Sat, Oct 11, 2014 at 09:40:49PM -0400, Steve Litt wrote: Now that I've said that, you can accomplish some pretty incredible things by gluing a few commands together. I wrote the better half of a http log evaluation program using a shellscript gluing together grep, cut, and awk, and piped the remainder (which was a much smaller data set than what went in) to a Python program or something like that. Don't try and replicate Perl, just use it. :) -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012022536.GB32189@tal
Re: Bash usage: was implicit linkage
Hi Steve: I agree that shell scripts are simplistic and not meant for fancy programs although it could be done, just not productive. But the nice thing is shell scripting is simplistic easy to learn and understand. Sure beats the days when I wrote code in Assembler, Cobol, Fortran, PL1, RPG, Easytrieve, Focus. Those days are gone with the likes of Perl, Pascal, C++, etc. Peter On 11/10/14 09:40 PM, Steve Litt wrote: On Sat, 11 Oct 2014 19:05:19 -0400 Doug dmcgarr...@optonline.net wrote: On 10/11/2014 05:28 PM, Steve Litt wrote: On Sat, 11 Oct 2014 21:21:14 +0300 Daemontools runscripts are incredibly simple shellscripts, that I'm sure you could write no sweat except in very wierd edge cases. Here's my run script for my home-grown cron substitute: == #!/bin/sh ### DON'T START littcrond UNTIL THE NETWORK'S UP ### pingaddr=8.8.8.8 pingaddr=192.168.100.96 echo littcrond checking network 12 while ! ping -q -c1 $pingaddr /dev/null; do sleep 1 echo littcrond REchecking network 12 done ### RUN THE DAEMON ### exec envuidgid slitt envdir ./env setuidgid slitt \ /d/at/python/littcron/littcron.py \ /d/at/python/littcron/crontab == The last three lines are really one line that wordwraps in email. If I hadn't checked for the network being up, this would have been a two line shellscript. I've known you (online) for several months, and although we sometimes disagree, I know you're pretty smart, so I'm positive you could have written this shellscript without breaking a sweat. /snip/ I've been using Linux seriously for about five years, altho I diddled around with it a bit earlier. About the time I started seriously using it, I took a course in Linux at the local community college, of which perhaps a third was devoted to scripting. Quite some time earlier, I had taken a course in Pascal, which I did very well in, and I actually wrote some useful code in that language for my job as an engineer. Prior to that, I used and wrote a lot of stuff in BASIC. Getting back to my Linux class, I received a B+. I don't know how much code I could have actually written when class was over, since one needs to know a lot more about system commands. At any rate, it's been about five years, and I could not now write the script you use to illustrate this message, and I'm not really sure I can read it! BASH scripts are written in perfectly logical code, quite similar, in fact, to Pascal. The problem is that they don't have the advantage of normal language; they rely on all sorts of abbreviations instead of the English words that more popular programming languages like Pascal, C, Python, and BASIC use. It's been probably 25 years since I wrote anything in Pascal or BASIC, but with about 30 minutes of reference-book research, I think I could go back and do it now. I can't imagine that to be true with BASH scripting. Just call me dufus. --doug Hi Doug, You're absolutely right. From my viewpoint, shellscripts were never intended to be big, huge programs. To me, they just glue together commands, and have a few rudimentary branching and looping constructs. Their loops are incredibly slow, you'd *never* do an inner loop in Bash. To me, if something involves you doing your own logic rather than calling other executables to do it, then Python, C, or some other real language is the way to do it. So yes, sysvinit startup scripts are on the far edge of what Bash should be used for. I'd say most daemontools run scripts are under 20 lines of code, so you'll be able to re-figure them, in a few minutes, six months from now. Now that I've said that, you can accomplish some pretty incredible things by gluing a few commands together. I wrote the better half of a http log evaluation program using a shellscript gluing together grep, cut, and awk, and piped the remainder (which was a much smaller data set than what went in) to a Python program or something like that. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5439f183.9070...@rogers.com
