Indoor European. I know #regex. I write #code (in #C or #Haskell or #Perl or #JavaScript or #bash).100% OPSEC.
Kompatibel mit handelsüblichen Klemmbausteinen.
Arguably, I never fully learned Bash syntax, but it also is just a stupid if-statement. There shouldn’t be that much complexity in it.
There isn't. The syntax is
if COMMANDthenCOMMAND(s)...elseCOMMAND(s)...fiI believe, if you write the then onto the next line, then you don’t need the semicolon.
Yes, but that's true of all commands.
foo; bar; bazis the same as
foobarbazAll the
]and-zstuff has nothing to do withif. In your example, the command you're running is literally called[. You're passing it three arguments:-z,"$var", and]. The]argument is technically pointless but included for aesthetic reasons to match the opening](if you wanted to, you could also writetest -z "$var"because[is just another name for thetestcommand).Since you can logically negate the exit status of every command (technically, every pipeline) by prefixing a
!, you could also write this as:if ! test "$var"; then ...The default mode of
test(if given one argument) is to check whether it is non-empty.Now, if you don't want to deal with the vagaries of the
testcommand and do a "native" string check, that would be:case "$var" in "") echo "empty";; *) echo "not empty";;esac@racketlauncher831 As far as the C compiler is concerned, there is literally no difference between those two notations. If you declare a function parameter as an array (of T), the C compiler automatically strips the size information (if any) and changes the type to pointer (to T).
(And if we're talking humans, then
char *args[]does not mean "follow this address to find a list of characters" because that's the syntax for "array of pointers", not "pointer to array".)@affiliate Hey, you didn't even mention that
char *args[]actually meanschar **argsin a parameter list.@stebo02 @Bogus5553 Neither of them require a return value, but
void mainisn't legal C++.Strictly speaking, it should be
Unsafe block syntax in C++
{ ...}That confirms exactly what tyler said. I'm not sure if you're misreading replies to your posts or misreading your own posts, but I think you're really missing the point.
Let's go through it point by point.
- tyler said "JSON Schema is not an ISO standard". As far as I can tell, this is true, and you have not presented any evidence to the contrary.
- tyler said "JSON Data Interchange Format is a standard, but it wasn’t published until 2017, and it doesn’t say anything about 1.0 needs to auto cast to 1". This is true and confirmed by your own link, which is a standard from 2017 that declares compatibility with RFC 8259 (tyler's link) and doesn't say anything about autocasting 1.0 to 0 (because that's semantics, and your ISO standard only describes syntax).
- tyler said "JSON Schema isn’t a specification of the language, it’s for defining a schema for your code", which is true (and you haven't disputed it).
Your response starts with "yes it is", but it's unclear what part you're disagreeing with, because your own link agrees with pretty much everything tyler said.
Even the part of the standard you're explicitly quoting does not say anything about 1.0 and 1 being the same number.
Why did you bring up JSON Schema (by linking to their website) in the first place? Were you just confused about the difference between JSON in general and JSON Schema?
@masterspace Love the confidence, but your facts could do with some work.
- "Interpreted language" is not a thing. Interpreted vs compiled is a property of a particular implementation, not the language.(I wonder how you would classify lazy functional languages like Haskell. The first implementations were all interpreters because it was not clear that the well-known graph reduction technique for lazy evaluation could be compiled to native code at all.Today, hugs (a Haskell interpreter written in C) isn't maintained anymore, but GHC still comes with both a native compiler (ghc) and an interpreter (runghc, ghci).)
- Most implementations that employ interpretation are compiler/interpreter hybrids. It is rare to find an interpreter that parses and directly executes each line of code before proceeding to the next (the major exception being shells/shell scripts). Instead they first compile the source code to an internal representation, which is then interpreted (or, in some cases, stored elsewhere, like Python's
.pycfiles or PHP's "opcache"). - You can tell something is a compile-time error if its occurrence anywhere in the file prevents the whole file from running. For example, if you take valid code and add a random
{at the end, none of the code will be executed (in Javascript, Python, Perl, PHP, C, Haskell, but not in shell scripts). - The original "lint" tool was developed because old C compilers did little to no error checking. (For example, they couldn't verify the number and type of arguments in function calls against the corresponding function definitions.) "Linting" specifically refers to doing extra checks (some of which may be more stylistic in nature, like a
/*FALLTHRU*/comment in switch statements) beyond what the compiler does by itself. - If I refer to an undeclared variable in a Perl function, none of the code runs, even if the function is defined at the end of the file and never called. It's a compile-time error (and I don't have to install and configure a linting tool first). The same is true of Haskell.What's funny to me is that Javascript copied
use strictdirectly from Perl (albeit as a string because Javascript doesn't haveusedeclarations), but turned it into a runtime check, which makes it a lot less useful.
Not to be rude but not having a linter configured and running is a pretty basic issue.
Yeah, if you're a C programmer in the 1980s, maybe. But it's 2006 now and compilers are able to do basic sanity checks all on their own.
I haven’t used Perl though, what do you like better about it?
"Undeclared variable" is a compile-time error.
@masterspace "Undeclared variable" is a runtime error.
Perl.
@Tangentism @Ephera Did you mean:
echo "${var:-empty}${var:+no it aint}"?