🐧 Lunix



  • In that case, everything discussed in this thread is a human error.



  • @ben_lubar said:

    In that case, everything discussed in this thread is a human error.

    Assuming we're all humans... Not sure about that...



  • @TwelveBaud said:

    You got DiscoMarkdowned.

    <tt>@"\\.\"</tt>


    Overall I think I should have stuck with triple backticks, then...

    Discsucks strikes again...



  • @Steve_The_Cynic said:

    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'...)


  • :belt_onion:

    @tar said:

    (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!


  • Discourse touched me in a no-no place

    @Steve_The_Cynic said:

    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!)



  • @dkf said:

    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.


  • Discourse touched me in a no-no place

    @tar said:

    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.


  • Discourse touched me in a no-no place

    @ben_lubar said:

    -Wall -Wextra -Werror -O2 -pedantic -Dickweed -funroll-loops -Where_its_at

    , surely


  • Discourse touched me in a no-no place

    I Jeffed 4+4 posts to an existing topic: Where bots got discussed in @blakeyrat's topic



  • @Onyx said:

    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.


  • BINNED

    Finally, a command
    line shell for the 90s

    Oh yeah! 🕶

    I guess I could give it a go. Will it pick up custom bash completion rules? apt-get and aptitude 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.



  • @RaceProUK said:

    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.


  • Java Dev

    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.

  • BINNED

    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 a date or datetime type rather than a simple string. You could also require every application to provide a toString() for it's types that the shell can call when you're just spitting stuff to STDOUT. 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 from STDIN.

    INB4 that's what PowerShell does. It might as well, I don't know much about it.


  • FoxDev

    @Onyx said:

    INB4 that's what PowerShell does

    I believe it does; it's built on .NET, and in .NET, everything is an Object, so everything has a ToString().


  • BINNED

    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 to STDOUT would be just a call to date's toString which would spit out a string based on your regional settings. Doing an equivalent of to_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


  • Java Dev

    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.


  • BINNED

    @PleegWat said:

    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.


  • Java Dev

    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.


  • BINNED

    @PleegWat said:

    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 printfs with a formatting structure that instructs the shell on what to print. That's what I mean with "providing a toString 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 one date 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.


  • Java Dev

    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.


  • BINNED

    @PleegWat said:

    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 with printfs? Yeah, definitely.

    I think this was a case of missing each other's points rather than a disagreement then.


  • Discourse touched me in a no-no place

    @PleegWat said:

    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.



  • @dkf said:

    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.

    🚎



  • @PleegWat said:

    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
    
    

    See here or here for more info...


  • BINNED

    @tar said:

    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



  • @Onyx said:

    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.



  • @EvanED said:

    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.



  • @EvanED said:

    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.



  • These design decisions predate the open source community by roughly a decade.



  • @OffByOne said:

    > 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.



  • @Onyx said:

    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!


  • FoxDev

    @riking said:

    And let's not even mention the fact that monolithic kernels have been the laughing stock of kernel designers for decades now.

    :wtf:
    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


  • BINNED

    I think @abarker was too focused on that tiara and completely forgot to give you glasses, or at least a monocle ;P


  • FoxDev

    @accalia said:

    :wtf:
    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:

    1. Don't whoosh 😛

  • Discourse touched me in a no-no place

    @RaceProUK said:

    Instructions on how not to get whoosh badgers:

    That sounds like an admission of flagging. Time to pile on, I guess. 🎏


  • FoxDev

    @FrostCat said:

    That sounds like an admission of flagging. Time to pile on, I guess. 🎏

    1. I never flag @accalia for whoosh, and she never flags me for same
    2. @accalia, I'm so sorry if you get another badger as a result of this…

  • Discourse touched me in a no-no place

    @RaceProUK said:

    I never flag @accalia for whoosh, and she never flags me for same

    Ah, you've banded together in a mutual self-defense pact.


  • FoxDev

    nah. it's more like if we didn't have an agreement we'd have an unresolved conflict of interests


  • FoxDev

    Really? I just don't flag because I know whoosh badges annoy you 😕


  • FoxDev

    well, yes. but my way sounds cooler!

    :rofl:


  • FoxDev

    @accalia said:

    well, yes. but my way sounds coolerlike legal mumbo jumbo!

    😛


  • FoxDev

    i may have been having lunches with a lawyer this week. :-P must have picked up some of the lingo.


  • FoxDev

    @accalia said:

    lunches with a lawyer this week

    Anything interesting? Or just boring legal stuff?


  • FoxDev

    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. ;-)


Log in to reply