check variable content size in sh script

[Teske, Devin]

On May 18, 2013, at 5:06 PM, Teske, Devin wrote:

> 
> On May 18, 2013, at 4:54 PM, Quartz wrote:
> 
>> 
>>> #foo works with sh
>> 
>> Is it actually part of the official spec though is what I'm wondering, or is it a case of other shells not rejecting 'advanced' statements when running in emulation.
>> 
> 
> Shells don't have an "emulation mode". The shell supports what it supports, and no shell that I've ever used had an "emulation mode" to act like another shell.
> 

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 act 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 compliant /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". That is to say that bash will more strictly adhere to POSIX bourne shell standards 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… you still have access to constructs such as ${#foo}.

All that being said… csh/tcsh has no such "standards comliancy mode" (what you called emulation). In fact… csh/tcsh don't follow the POSIX standards (or if it does… *extremely* loosely; see "handling of file descriptors" below in replied-to text).
-- 
Devin


> Maybe you're referring to as "emulation" is actually the invocation line of the shell script.
> 
> Make no mistake… when you change the invocation (first) line of a shell script from:
> 
> 	#/bin/sh
> 
> to:
> 
> 	#/bin/tcsh
> 
> You are not instructing a shell to "emulate" anything, you are actually using a different shell.
> 
> sh != tcsh != bash != ash != dash != zsh
> 
> 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.
> 
> 
> 
>> 
>>> At least FreeBSD's implementation of sh (which is ash, I think)
>>> supports the # functionality.
>> 
>> The reason I say all this is that my copy of tcsh (on this not-freebsd machine) *doesn't* work with this when in sh emulation.
>> 
> 
> Get the idea that "csh" or "tcsh" are *anything* like sh out of your mind.
> 
> Further, you almost *never* want to do any serious shell programming in csh or tcsh.
> 
> Why? Because csh and tcsh have an incomplete programming spec. Most notably are the way that it handles pipe data and the standard-output/error file descriptors. Specifically, you cannot throw away stdout while keeping stderr. 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 sense that it has a complete programming specification).
> 
> I personally never recommend csh/tcsh as a scripting language… but I can see the benefit that certain constructs (like "repeat N cmd") have, purely for their simplicity (and readability for *very* short scripts). To challenge myself on this topic, I routinely try and cross-port very complex shell scripts to csh, and while I can do math with "let" and I can other things that a *normal* scripting language should allow… I invariably end up running away screaming in frustration.
> 
> Again,
> 
> csh != tcsh != sh != bash != ash != dash != zsh
> -- 
> Devin
> 
> _____________
> The information contained in this message is proprietary and/or confidential. 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 aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

_____________
The information contained in this message is proprietary and/or confidential. 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 aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.