Date: Sun, 19 May 2013 00:13:27 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Devin Teske <dteske@freebsd.org> Cc: "<freebsd-questions@freebsd.org>" <freebsd-questions@freebsd.org> Subject: Re: check variable content size in sh script Message-ID: <13CA24D6AB415D428143D44749F57D7201F50963@ltcfiswmsgmb26> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201F508F2@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201F50963>