On Thu, Feb 20, 2014 at 09:52:23PM +0100, David Caro wrote: What are the advantages in your opinion? I like the $() construct and local variables. Associative arrays can come up handy. I have the opposite sentiment - diversions from the standard should be kept small and well-justified. Could you detail where [1] is different from the http://wiki.bash-hackers.org/scripting/style that it cites? BTW, it's missing the most important rule, that can turn the shell into a programming language: the -e option. Not using it is basically equivalent to wrapping every python line within its own try-except-pass block.

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JmDNeoq8Ebv1nqkSd8BNHALVJ2SuOPi93 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable El 21/02/14 00:37, Dan Kenigsberg escribi=F3: shell I created existing because I ugh ntenance * Less prone to errors: - [[ ]] builtin constructs make it really easy to avoid having errors w= hen spaces are in the tested variable: myfile=3D"/thi/is my/file" [[ -f $myfile ]] <- this does not break and works as expected [ -f $myfile ] <- this breaks - Long options are really nice and make code clearer - Arrays are useful - Associative arrays are useful too - String expansions with brackets mv myfile{,.bkp} - Pattern substitution: ${myvar/mypatt/mysub} - Substring expansion: ${myvar:offset:length} - Indirect variable expansion (don't use it if you don't need it, like = eval): ${!myvar} - $PIPESTATUS array, with the return codes of the commands executed in = a pipe - options in echo (echo -e, echo -n, ...) - local variables definition, there's no local in POSIX: local a b c <- this is not POSIX - source command (a lot clearer than '.', harder to confuse with execut= ion) - select command to create menus - the time builtin (not a builtin in POSIX) - Process substitution redirection: foo <( bar ) - '=3D=3D' equality test instead of '=3D' (A lot more readable and less= confusing) - '<>' lexicographical comparison - Check if 2 files are the same hard link: [[ $file1 -ef $file2 ]] - Redirecting stdin and stdout: &>, >& and &| - duplication and closure of file descriptions: m>&n- - Herestrings ('<<<') - A lot of the shopt options - FUNCNAME to get current function name - REGEXP matching test (=3D~) Those are a few, there are more differences but some of them I don't reco= mmend (that's why we are creating a style guide, to use only the ones that real= ly help) scripts to n the far I heard this before from Alon, in my opinion, both of you have the wrong = idea of what a standard is and when to apply it. POSIX standard is a standard created to allow portability between operati= ng systems, that's it's goal. The infrastructure scripts will most likely ne= ver be run outside the GNU family of operating systems (fedora/centos/ubuntu/debian/suse/gentoo ...) so the portability is not something that matters. Thus, the application of the POSIX standard is too restrictive. Imagine i= t like building your house in Norway with the same standards that are used in To= kyo, you don't need protection from eathquakes, you need heat efficiency. The same way, we don't need portability, we need flexibility and error av= oidance. As I said also, at the end of the script and at the end of the wiki, if y= ou are gonna distribute a script with the product, then POSIX standard is the on= e that should be applied. inions and Some of the differences are: - Indentation (I said 4 spaces and that the consistency in using tabs o= r spaces throughout the script is more important than using spaces) - I let case constructs to fit in one line if they are short (one comma= nd) - Added the 'local' usage on the function variables - Recommended to use function parameters instead of global variables - Recommended to specify a return statement explicitly - Using builtins instead of external commands when possible - Added portability note Most of those are from here, a german linux user group: http://lug.fh-swf.de/vim/vim-bash/StyleGuideShell.en.pdf And I want to finish looking that one up and incorporate the best advice = from there too (the testing section is nice, and the comments) -e option is useful yes, but not always so helpful, agree that in the bes= t case you should use it. But sometimes is not so simple and people end up writi= ng '|| :' at the end of each command. I planned on adding more about bash options to the wiki, and also some debugging, but did not have the time. Point taken. oject. andard Let's write everything in javascript so we can all contribute to engine a= nd is the only language that can fit everywhere (ui included)... the goal of th= e product is different from the goal of infra, the tools should be the best= suited for the goals of the team, and if we can choose the same tools without lo= osing focus towards our goals then we should. I'm not sure either of the percentage of shell scripts that are there in product, but I'd say that it's not that much, as most of it are make scri= pts and relatives. I don't agree, POSIX standard makes code a lot less readable if not using= 'extensions': ssh -tNL 1234:127.0.0.1:4321=09 ### Imaginary non-POSIX compliant ssh that uses GNU extensions ssh --force-tty --no-command --local-tunnel 1234:127.0.0.1:4321 [[ "${myvar: -1}" =3D=3D "/" ]] ## the variable ends with '/' [ "$(printf "$myvar" | tail -c 1)" =3D "/" ] ## remember that echo -n = is not posix compliant do_something &>something.log do_something 1>something.log 2>&1 Or any case where you have to go to sed/awk/python/ruby to get rid of the= POSIX restrictions and use their own programming languages. Having to understan= d 2 languages to read a script is less readable than having to understand 1 i= mo. Having to expose all the variables as global is also less readable and a = lot more prone to errors too. do_whatever() { for i in one two; do echo "inside i =3D $i" done } for i in three four; do do_whatever echo "outside i =3D $i" done The output of that is: inside i =3D one inside i =3D two outside i =3D two inside i =3D one inside i =3D two outside i =3D two The non-POSIX equivalent using local does what you expected: do_whatever() { local i for i in one two; do echo "inside i =3D $i" done } for i in three four; do do_whatever echo "outside i =3D $i" done inside i =3D one inside i =3D two outside i =3D three inside i =3D one inside i =3D two outside i =3D four The fact that you expect the code to do something and it does something e= lse goes inside non readable to me (because it's not easy to understand what = it does reading it). --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --JmDNeoq8Ebv1nqkSd8BNHALVJ2SuOPi93 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" --JmDNeoq8Ebv1nqkSd8BNHALVJ2SuOPi93--

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7LlLSFtSeQ5ghwb0MBCWli17vr8PoOO5x Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 21/02/14 00:40, Alon Bar-Lev escribi=C3=B3: shell I because ugh scripts n the inions se bash. g. chy. =46rom the company you work for, and a pretty old and active participatio= n on open source projects, Dave (cc'd) seems to disagree with your view of open sou= rce management: https://opensource.com/business/11/2/leadership-open-source-communities """ So how are open source communities led? Largely by the people doing the w= ork. Most groups have a loosely defined common goal (build software widgets, o= r develop a awesome, open source, computer-based fourth grade math curricul= um), and decisions are made by the people doing the work. There's no manager i= n place dictating edicts about how things must be done or what objectives to seek= after. Many people object to this method, call it anarchy, and claim that it imp= edes progress. It's true that if the same set of people was coerced into a sin= gle direction, they might make more progress, but there likely wouldn't be th= e same level of innovation. """ t important, however, standards compliance is something that should be co= nsidered. --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --7LlLSFtSeQ5ghwb0MBCWli17vr8PoOO5x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" --7LlLSFtSeQ5ghwb0MBCWli17vr8PoOO5x--

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'll reply to Allon's email separately, but... On 02/21/2014 11:01 AM, David Caro wrote: Leadership in open source communities Posted 8 Feb 2011 by David Nalley (so, not me) :-) I do agree with this. However: people will look to a leader to figure out what should be done, in what priority, and who has the authority to give access to things required to get stuff done. In the absence of an existing hierarchy, you quickly end up in gridlock. The loosely defined common goal is important. Let's take patches as an example. Anyone can write code to implement a feature, fix a bug, whatever - but someone needs to merge the patches, bundle up a release, exercise some level of discretion, and give some guidance as to whether contributed patches will be accepted or not by setting a direction. I don't think that a strict hierarchy is needed. But seeding the group with the people doing the work is important. And that's what we've done, I think - clearly, David, Eyal, Ewoud, Rydekull, Kiril, quaid and myself have the knowledge and do the work (with different levels of skills and knowledge for different pieces of the infrastructure), and get to say who gets access to resources and whether contributions come up to our standards or not. Cheers, Dave. >> As for infra, it is not part of anything we distribute so it is >> not that important, however, standards compliance is something >> that should be considered. >>>>>>>> [1] http://www.ovirt.org/Bash_style_guide >>>>> Cheers! >>>>> -- David Caro >>>>> Red Hat S.L. Continuous Integration Engineer - EMEA ENG >>> Virtualization R&D >>>>> Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: >>> 82-62605 >>>>>>> _______________________________________________ Infra mailing >>> list Infra(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/infra >> - -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13

----- Original Message ----- +1, i also believe that it's better to write code that is easy to read and maintain rather than to make a special effort to be compliant for something is will not necessarily be needed. it sometimes can add unnecessarily delays to a certain needed infra task, for the wrong reasons imo. if an infra member has a strong previous experience with POSIX rather bash bash, not sure this should be enforced, but other than that i think that having a base guideline for writing infra scripts is a good thing. ultimately, i think the final decision for how to write the code stands in the hands of who's writing it, and we shouldn't block / -1 patches just on style (bash/posix) and focus on the logic / correctness of the code. Eyal.