🐧 Lunix
-
In that case, everything discussed in this thread is a human error.
-
In that case, everything discussed in this thread is a human error.
Assuming we're all humans... Not sure about that...
-
You got DiscoMarkdowned.
<tt>@"\\.\"</tt>
Overall I think I should have stuck with triple backticks, then...Discsucks strikes again...
-
Discsucks strikes again...
Yeah, I'm not sure that Discourse is optimized for use by programmers (or anyone who wants any kind of formatting other than 'just text'...)
-
(or anyone who wants any kind of "formatting" other than "'just text' when Discourse decides not to mangle my 'just text' text"...)
What, empty post? Me? No, say it isn't so!
-
Overall I think I should have stuck with triple backticks, then...
Just throw some more backslashes in until what you want shows up in preview. (Or throw in some slashes, if you think that
/
is a backslash. I've seen people mix that up!)
-
Just throw some more backslashes in until what you want shows up in preview. (Or throw in some slashes, if you think that
/
is a backslash. I've seen people mix that up!)
Yeah, I've seen that. I don't really get it, but maybe it's just a sign of erratic education. Or stupidity. Or something.
-
But FORTRAN already exists?
You joke, but I remember back in the early 90s reading about some scripting language they'd written at CMU, where someone hosed the parser such that func("param"), func$"param"$, func "param", and so on, all worked the same way.
-
-
I Jeffed 4+4 posts to an existing topic: Where bots got discussed in @blakeyrat's topic
-
For now, I can live with bash for basic day-to-day operations and script stuff in something else when going gets tough in bash. And I'll be the first one to throw it in
/dev/null
the day something better becomes the standard. But for now, bash is ubiquitous and I'll stick to that for scripting because I know it will work on 99.99% of Linux systems I want to use it on.Stick to bash for scripting and use fish for interactive command line stuff.
-
Finally, a command
line shell for the 90sOh yeah!
I guess I could give it a go. Will it pick up custom bash completion rules?
apt-get
andaptitude
add some of their own if I understood how package name completion works correctly.
-
Those shell out to bash to run the completions. It doesn't matter which shell you're using.
But please do not use bash for scripting when you can so easily avoid it. Use Perl, Python, Ruby, etc. Really. Please. Bash is (just barely) okay for interacting, because most interactions are fairly simple. But it's a horrible language for scripting.
-
Argument passing? Tricky. Ideally, I'd want the user to define a data structure to pass as an object, but that might make the CLI too hard to use. But having a space-separated string is not good either.
My suggestion:
From a code standpoint there is only one single argument passed to an executable and output from an executable, which consists of a simple dynamic object format supporting numbers, strings, arrays, objects and arbitrary nesting. (Really, you would just take a simple interchange format like JSON as the canonical internal format and build sugar around that.)
From a shell standpoint, it's really up to the shell of choice how to work with the standardized input format. However, piping output to a next input is always done directly, without the shell intervening and inserting any kind of conversion. Output conversion only happens if the shell has to display something.
As for input conversion: a nice example is that for convenience sake, a shell could allow multiple arguments and they automatically get normalized into a single array argument before being passed into the executable.
-
Yes, a loosely-structured mechanism like that would be best. It would also be a good idea to use the same type for arguments and pipes, so you can easily use the output of one program as the argument of another.
However, I do not think standard JSON is a good format. IMO there are 2 required features standard JSON doesn't have:
- A stream-based 'root' type. This could just be the special assumption that if the root type is a json array, the first element can be parsed and processed without necessarily waiting for the second element to arrive.
- Some support for fixed-size records and binary data, without requiring the encoding/decoding/searching for end-of-string markers that would be involved in escaping or base64 encoding.
-
I'd be more inclined to use something akin to XML (yes, I know, boo, evil, hear me out).
Fixed sized records would be nicely serviced by having additional attributes available to indicate size, type of stream etc.
The other thing I'd like to see is types. You could have
date
spit out it's output as adate
ordatetime
type rather than a simple string. You could also require every application to provide atoString()
for it's types that the shell can call when you're just spitting stuff toSTDOUT
. And you could also have cast semantics built in into the shell so you can manually cast stuff to text if need be when feeding the output into a legacy application that can't speak the fancy new language and just expects strings fromSTDIN
.INB4 that's what PowerShell does. It might as well, I don't know much about it.
-
INB4 that's what PowerShell does
I believe it does; it's built on .NET, and in .NET, everything is anObject
, so everything has aToString()
.
-
Nice.
I was mostly thinking about how you deal with this stuff in an RMDBS. You can have implicit casts (implementing toString in my model would be defining that within the application itself), and explicit casts which I'd have as a feature of the shell. So if you want to format data differently you could have a cast syntax in the shell which would override the implicit cast that the application provides.
To use the
date
example again: Trying to print the output toSTDOUT
would be just a call todate
'stoString
which would spit out a string based on your regional settings. Doing an equivalent ofto_char(date, 'YYYY-MM-DD HH24:MI:SS')
would override that and print stuff out in ISO format (more or less, I didn't include all the minutae in the cast).
-
http://rwd.rdockins.name/shellac/home/
+
Haskell type classes to define "interfaces"
=
The solution
-
XML could definitely fit the bill as well. Display is definitely an issue, but that's independent of transfer format. I don't see a good avenue into 'providing toString()' on a multiple-independent-binaries level.
The
date
program could return an XML structure that contains the current (or specified) date. However, it would be on either the shell, or some shared library loaded by the shell to convert that type to string.Also, I think it is important to have a flexible structure. If I add a new
frizzle-value
to my program, I don't want to have to recompile/restart the shell as well for it to handle the property.
-
The date program could return an XML structure that contains the current (or specified) date. However, it would be on either the shell, or some shared library loaded by the shell to convert that type to string.
My idea was that you had to provide the instructions on how to convert the output to a string. It might as well be the shell that does it, but you should be the one telling it how to format it.
-
Yes, but you don't want that to be a new program invocation later in the pipeline. Especially not for each value that needs to be shown. Hence a shared library or shell builtin.
-
Yes, but you don't want that to be a new program invocation later in the pipeline.
I never advocated that.
I agree that it should be a shell builtin that can probe the program for "hey, what's the format I should use to convert this to string?". You pretty much replace your
printf
s with a formatting structure that instructs the shell on what to print. That's what I mean with "providing atoString
method", maybe I oversimplified it a bit in my original explanation.You also gain the "casting" ability that way. Say you're writing a script. You need to feed the output of
date
into something that can only handle strings, and it wants them in a different format than the onedate
spits out by default, or you want to make sure you don't get screwed by regional settings. So you "cast" it in shell - you tell the shell not to use the default format the program provides, but to format it based on the format string you give it.Also note that, ideally, the casting bit is pretty much useless if you could guarantee that every program will know how to use the universal interchange format. I mostly wanted that bit included to provide a compatibility layer for "legacy" programs.
-
I guess you could send tostring bytecode over the pipe, but I'd want to limit what to do on that front. Consider, for starters:
- Mode: Integer in transfer,
drwxr-xr-x
in display. - User/group: ID in transfer, name in display
You need to keep the formatting code somewhere external. Either as a loadable library, or as some form of bytecode. And the interpretation of that needs to exist in the shell.
- Mode: Integer in transfer,
-
You need to keep the formatting code somewhere external. Either as a loadable library, or as some form of bytecode. And the interpretation of that needs to exist in the shell.
Oh, you mean have
libshellformat
or something that you use for all the formatting instead of letting everyone run amok withprintf
s? Yeah, definitely.I think this was a case of missing each other's points rather than a disagreement then.
-
I guess you could send tostring bytecode over the pipe
That's probably ill-advised, since you can't be sure that the other end of the pipe is in the same security context. Doing code that can be automatically moved between security contexts gets “exciting” quickly. (It's very easy to fuck up and make security hole, which is difficult to spot until someone exploits it and makes you look like a moron.)
Strings, for all that they suck in a number of ways, have a much lower comparative potential for security holes.
-
It's very easy to fuck up and make security hole, which is difficult to spot until someone exploits it and makes you look like a moron.
It's simple. We disallow backwards branches.
-
It would also be a good idea to use the same type for arguments and pipes, so you can easily use the output of one program as the argument of another.
PowerShell lets you "splat" arguments out of a hashtable into a command line, something like this:
PS> $parms = @{ 'class'='Win32_BIOS'; 'computername'='SERVER-R2'; 'filter'='drivetype=3'; 'credential'='Administrator' } PS> Get-WmiObject @parms
-
parms
:twitch:
Also, what's with the format? Ok, it's not hard to figure out and remember, but it's neither INI nor JSON. Is that a thing I'm not familiar with, or are we inventing new shit again?
Otherwise, yeah, that's cool.
Filed under: The NIH is strong in this one
-
Also, what's with the format? Ok, it's not hard to figure out and remember, but it's neither INI nor JSON. Is that a thing I'm not familiar with, or are we inventing new shit again?
A new form of C# object initializer syntax for
Dictionary<TKey,TValue>
and such classes, iirc.
-
These are things that I'm not actually sure how to deal with, because my vision is not a matrix of characters and it's really unclear if it can be made to even emulate that. I don't have a good plan for that either; probably I'll just revert to saying that things that get much more complicated than color codes have to be run in an existing terminal.
(FWIW, I actually kinda started on the terminal as well. :-) The display is Webkit, if that gives you an idea of having something that's very different.)
Care to elaborate? It sounds really cool and refreshing, but I can't form a mental picture of what you're envisioning.
-
do-something --to-these-files *
could be made to work right on Windows, but not Linux.If you escape the
*
, it will work right. Eitherdo-something --to-these-files \*
ordo-something --to-these-files "*"
prevents the shell from expanding the*
and it will be passed to the program as a literal asterisk.
-
These design decisions predate the open source community by roughly a decade.
-
> do-something --to-these-files * could be made to work right on Windows, but not Linux.
If you escape the *, it will work right. Either do-something --to-these-files \* or do-something --to-these-files "*" prevents the shell from expanding the * and it will be passed to the program as a literal asterisk.
This exact thing is done regularly for passing -name and -iname and -regex and -iregex options to find.
-
are we inventing new shit again?
PowerShell, brought to you by Microsoft: we never saw a technology that we didn't make our own version of...
-
Well, they haven't made a vacuum cleaner yet.
-
Linux is a broken design (as evidenced by being monolithic) based on a university student's pet project and a programming language that is broken in almost every imaginable way. It defies any attempt to make it more modular ("modules" are loaded into the monolithic kernel process). And let's not even mention the fact that monolithic kernels have been the laughing stock of kernel designers for decades now. See, I can troll as well!
-
And let's not even mention the fact that monolithic kernels have been the laughing stock of kernel designers for decades now.
please, correct me if i'm wrong here but isn't the Windows NT kernel also monolithic, with dynamically loaded modules (device drivers))?whooshy - abarker
-
I think @abarker was too focused on that tiara and completely forgot to give you glasses, or at least a monocle ;P
-
please, correct me if i'm wrong here but isn't the Windows NT kernel also monolithic, with dynamically loaded modules (device drivers))?
Instructions on how not to get whoosh badgers:- Don't whoosh
-
Instructions on how not to get whoosh badgers:
That sounds like an admission of flagging. Time to pile on, I guess.
-
That sounds like an admission of flagging. Time to pile on, I guess.
-
I never flag @accalia for whoosh, and she never flags me for same
Ah, you've banded together in a mutual self-defense pact.
-
nah. it's more like if we didn't have an agreement we'd have an unresolved conflict of interests
-
Really? I just don't flag because I know whoosh badges annoy you
-
well, yes. but my way sounds cooler!
-
-
i may have been having lunches with a lawyer this week. :-P must have picked up some of the lingo.
-
-
old friend in town on other business and decided to catch up. lots of banter and reminiscing about the good parts of the bad old days of high school. ;-)