From owner-freebsd-questions@FreeBSD.ORG Sun May 19 00:13:29 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AA72C291; Sun, 19 May 2013 00:13:29 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 77230AC8; Sun, 19 May 2013 00:13:29 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r4J0DS1x027337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 18 May 2013 19:13:28 -0500 Received: from LTCFISWMSGMB26.FNFIS.com ([10.132.99.18]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Sat, 18 May 2013 19:13:28 -0500 From: "Teske, Devin" To: Devin Teske Subject: Re: check variable content size in sh script Thread-Topic: check variable content size in sh script Thread-Index: AQHOUkc8OBFwBehJxk+zMS+kIvSMRZkIQzQAgAAKzgCAAxSDAIAAAS6AgAAMpACAAAJBAIAAgqyAgAADgICAAAHdgA== Date: Sun, 19 May 2013 00:13:27 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201F50963@ltcfiswmsgmb26> References: <5194F65F.6080503@a1poweruser.com> <5194FB0A.9090400@tundraware.com> <13CA24D6AB415D428143D44749F57D7201F4D41F@ltcfiswmsgmb26> <5197998E.6050200@sneakertech.com> <51979A8B.8080703@tundraware.com> <5197A526.7020302@sneakertech.com> <20130518180634.9e5fd3c2.freebsd@edvax.de> <519814A7.8070702@sneakertech.com> <13CA24D6AB415D428143D44749F57D7201F508F2@ltcfiswmsgmb26> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201F508F2@ltcfiswmsgmb26> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="Windows-1252" Content-ID: <17E8B62C93CED544A571D62DB5C4E97E@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-18_08:2013-05-17,2013-05-18,1970-01-01 signatures=0 Cc: "" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 00:13:29 -0000 On May 18, 2013, at 5:06 PM, Teske, Devin wrote: >=20 > On May 18, 2013, at 4:54 PM, Quartz wrote: >=20 >>=20 >>> #foo works with sh >>=20 >> Is it actually part of the official spec though is what I'm wondering, o= r is it a case of other shells not rejecting 'advanced' statements when run= ning in emulation. >>=20 >=20 > Shells don't have an "emulation mode". The shell supports what it support= s, and no shell that I've ever used had an "emulation mode" to act like ano= ther shell. >=20 I say this from a FreeBSD context. It may entirely be possible that a Linux= distro uses bash in /bin/sh -- and it's entirely possible that bash may ac= t differently if ARGV[0] is /bin/sh. But I wouldn't call this emulation. I'= d call it standardization. When bash is invoked with an ARGV[0] of bash or "{anything}/bash", it will = act "more like bash" and "less like standardized bourne shell, aka POSIX co= mpliant /bin/sh" (notice I didn't insert the name of any other shell, like = ash, dash, etc. but instead I said "like [a] standardized bourne shell". Th= at is to say that bash will more strictly adhere to POSIX bourne shell stan= dards when ARGV[0] is /bin/sh versus "bash". Even when bash clamps down on the bash-specific features if/when ARGV[0] is= /bin/sh=85 you still have access to constructs such as ${#foo}. All that being said=85 csh/tcsh has no such "standards comliancy mode" (wha= t you called emulation). In fact=85 csh/tcsh don't follow the POSIX standar= ds (or if it does=85 *extremely* loosely; see "handling of file descriptors= " below in replied-to text). --=20 Devin > Maybe you're referring to as "emulation" is actually the invocation line = of the shell script. >=20 > Make no mistake=85 when you change the invocation (first) line of a shell= script from: >=20 > #/bin/sh >=20 > to: >=20 > #/bin/tcsh >=20 > You are not instructing a shell to "emulate" anything, you are actually u= sing a different shell. >=20 > sh !=3D tcsh !=3D bash !=3D ash !=3D dash !=3D zsh >=20 > Your script will use the shell that is written in the innovation line and= the features you get are respective to which shell you choose. >=20 >=20 >=20 >>=20 >>> At least FreeBSD's implementation of sh (which is ash, I think) >>> supports the # functionality. >>=20 >> The reason I say all this is that my copy of tcsh (on this not-freebsd m= achine) *doesn't* work with this when in sh emulation. >>=20 >=20 > Get the idea that "csh" or "tcsh" are *anything* like sh out of your mind. >=20 > Further, you almost *never* want to do any serious shell programming in c= sh or tcsh. >=20 > Why? Because csh and tcsh have an incomplete programming spec. Most notab= ly are the way that it handles pipe data and the standard-output/error file= descriptors. Specifically, you cannot throw away stdout while keeping stde= rr. This short-coming may not be noticeable to all programmers that choose = csh/tcsh, but if you want to do any serious programming, you'll eventually = hit those limitations and be forced to move to a real shell (real in the se= nse that it has a complete programming specification). >=20 > I personally never recommend csh/tcsh as a scripting language=85 but I ca= n see the benefit that certain constructs (like "repeat N cmd") have, purel= y for their simplicity (and readability for *very* short scripts). To chall= enge myself on this topic, I routinely try and cross-port very complex shel= l scripts to csh, and while I can do math with "let" and I can other things= that a *normal* scripting language should allow=85 I invariably end up run= ning away screaming in frustration. >=20 > Again, >=20 > csh !=3D tcsh !=3D sh !=3D bash !=3D ash !=3D dash !=3D zsh > --=20 > Devin >=20 > _____________ > The information contained in this message is proprietary and/or confident= ial. If you are not the intended recipient, please: (i) delete the message = and all copies; (ii) do not disclose, distribute or use the message in any = manner; and (iii) notify the sender immediately. In addition, please be awa= re that any message addressed to our domain is subject to archiving and rev= iew by persons other than the intended recipient. Thank you. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o= rg" _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.