Announcement

Collapse
No announcement yet.

Microsoft's PowerShell Now Available On Ubuntu In Snap Form

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by cybertraveler View Post

    Short options generally don't have or get used with parameters. It wouldn't be -a Foo, it would be --all-files=1.

    Most commands are of the form:

    COMMAND-NAME OPTIONS FILE

    Most OPTIONS are GNU style which means short options can be appended together such that -a -f -1 can be contracted down to -af1. Long options have 2 leading dashes and parameters can be passed to them using an equals delimiter. Most commands seem to accept both an equals delimiter or space (new parameter) delimiter.

    Indeed, "-a" doesn't mean the same thing everywhere, but that would not be practically possible when you consider their are only about 62 possible combinations (upper case letters, lowercase letters and numbers). There are however very common conventions, eg:
    • -h will almost always print help info and exit
    • -V will almost always print a version number and exit
    • -v will almost always increase output verbosity
    • -q will almost always make the command quiet (no output on stdout)
    • - will almost always mean get input from stdin instead of from a FILE
    There are many common and widely followed conventions in UNIX, bash, GNU, POSIX and in Linux distros.

    Regular users of bash will often quickly remember the meaning of common short options.

    POSIX (including the shell and the common commands) is not perfect but it's good enough, it's powerful and it's widely available.

    Lots of people also happen to already 'speak' the POSIX language and they don't want to learn a new and unpopular language when POSIX serves them well. As a speaker of POSIX I can tell you purely from my own memory that -a...
    • in tar means select a compression algorithm based on the file extension
    • in man means show all man pages one after the other.
    • in ls means show hidden files in the output (I think it also shows . and ..)
    • in rsync means use 'archive' mode
    • in netstat means that the listening sockets should also be shown
    I can't tell you a single PowerShell option. I don't even know what PowerShell options look like. There's no way that PowerShell is going to gain significant traction in the GNU/Linux world. It's a whole new language that none of us speak that came from an organisation that many of us despise.
    I'm sorry you wrote all of that, I was aware of most of it. That said, there are still plenty of things that will trip people up. find doesn't follow the expected ordering. dd doesn't either. Quoting rules inside shell scripts and in certain command invocations are arcane and error messages are often confusing. I've already climbed this learning curve, and so have you, but that doesn't mean it's a good learning curve.

    I'm not saying Windows is better. It isn't, it's worse. But I think the attention to consistency in PowerShell is admirable, even if it's not nearly enough to make it worth the effort to replace the GNU Coreutils and bash with PowerShell equivalents in some Linux distribution.

    But most of all I just get annoyed with the constantly repeated misinformation:

    1. I hate Microsoft as much as the next open source enthusiast, but FUD over their Embrace, Extend, Extinguish strategy just makes us look like lunatics. PowerShell for Linux is 100% open source, free-as-in-freedom software. There is plenty of real Microsoft EEE for us to hate elsewhere, just not here.

    2. PowerShell does not require complex object-manipulation or object-oriented-programming to use. This article, for example, walks through PowerShell equivalents to a series of common grep examples. The syntax is very different from bash + grep, but not hard to read and understand https://communary.net/2014/11/10/gre...owershell-way/

    Comment


    • #32
      Originally posted by Michael_S View Post
      I'm sorry you wrote all of that, I was aware of most of it. That said, there are still plenty of things that will trip people up. find doesn't follow the expected ordering. dd doesn't either. Quoting rules inside shell scripts and in certain command invocations are arcane and error messages are often confusing. I've already climbed this learning curve, and so have you, but that doesn't mean it's a good learning curve.
      My point was that it's not almost complete chaos and inconsistency. There are a lot of widely followed patterns. It bugs me that the find command does not follow the patterns because I like that command, but I have remembered its usage anyway.

      I've noticed that newly created software and software forks often follow the more modern conventions. For example: mplayer didn't follow conventions well when I used to use it, but 'mpv' (the popular fork of mplayer that Michael sometimes mentions) seems to follow all the conventions.

      Originally posted by Michael_S View Post
      I'm not saying Windows is better. It isn't, it's worse. But I think the attention to consistency in PowerShell is admirable, even if it's not nearly enough to make it worth the effort to replace the GNU Coreutils and bash with PowerShell equivalents in some Linux distribution.
      Yeah: it sounds nice, but it's not good enough. Maybe one day someone will come up with a new shell design to replace the bash/GNU/POSIX/Linux stuff that is so incredibly good that people will make an effort to widely adopt it. I think this has happened with Meson and CMake. The GNU Autotools stuff is so much worse than Meson and CMake that vast numbers of projects are making the large effort to switch over to one of them.

      Originally posted by Michael_S View Post
      1. I hate Microsoft as much as the next open source enthusiast, but FUD over their Embrace, Extend, Extinguish strategy just makes us look like lunatics. PowerShell for Linux is 100% open source, free-as-in-freedom software. There is plenty of real Microsoft EEE for us to hate elsewhere, just not here.
      Are you sure that being Open Source is enough? I'm not.

      The controller of a dominant implementation of software can influence all forks for the same reason that the POSIX environment hasn't been replaced even though there are likely technically and ergonomically superior alternatives. If PowerShell did get very popular and people started writing alternative implementations or creating forks of it, the Microsoft implementation would remain the defacto rolling-standard for as long as Microsoft had the plurality of the PowerShell implementation market. If Microsoft changed something or added something that people generally didn't like, all the forks and alternative implementations would likely implement these things just to remain compatible. There would be a limit to what people would accept, but the process of finding that limit and then eventually departing from Microsoft would be long, stressful and messy: as has been the case with Internet Explorer.

      A friendly company with care for communities, culture and people in general might not use their plurality control of a market to push features people generally didn't want. Microsoft are historically not friendly at all. There are some signs that Microsoft's internal culture is changing, but I think it is wise for people to be highly sceptical of Microsoft considering their track record and how much damage they have already done.

      There are many stories and allegories of snakes that are friendly at first. They whisper nice things in your ear and help out. You start to believe that the snake is friendly and empathetic like yourself. But once you let the snake in your life and you give it trust, it strikes while you are vulnerable and bites you getting exactly what it wanted from the start.

      Microsoft: Fool me once: shame on you. Fool me twice: shame on me. Fool me for the TENTH TIME RUNNING... OK FINE! I've learned my lesson

      Originally posted by Michael_S View Post
      2. PowerShell does not require complex object-manipulation or object-oriented-programming to use. This article, for example, walks through PowerShell equivalents to a series of common grep examples. The syntax is very different from bash + grep, but not hard to read and understand https://communary.net/2014/11/10/gre...owershell-way/
      Thanks for the link. The syntax does look familiar.

      It seems odd to me that long options are prefixed with a single dash the same way as short options. This means that the options -F -l -i -p could not be contracted down to -Flip without risking ambiguity when there is a long option named "-Flip". I don't know how program designers are supposed to avoid these collisions. Perhaps upper case short options are not permitted. Or perhaps they just don't care because the chance of a collision is probably quite low. Feels nasty though. The GNU project solved this problem quite nicely with their solution.

      I also noticed that the position of the options for sls does seem to vary throughout the article. For example, the following are found in the article:
      Code:
      sls -n go .\demo_text.txt
      sls this .\demo_text.txt -ca

      Comment


      • #33
        Originally posted by cybertraveler View Post

        My point was that it's not almost complete chaos and inconsistency. There are a lot of widely followed patterns. It bugs me that the find command does not follow the patterns because I like that command, but I have remembered its usage anyway.

        I've noticed that newly created software and software forks often follow the more modern conventions. For example: mplayer didn't follow conventions well when I used to use it, but 'mpv' (the popular fork of mplayer that Michael sometimes mentions) seems to follow all the conventions.
        Good points, but I still think there's a lot to trap the unwary for the individual commands. I also think bash, ksh, csh, and so forth are nearly as ugly and awkward to use for complex tasks as Microsoft's own .cmd/.bat rules. Python, Perl, PowerShell, and for that matter Ruby or Scheme all represent substantial improvements.

        Originally posted by cybertraveler View Post
        Yeah: it sounds nice, but it's not good enough. Maybe one day someone will come up with a new shell design to replace the bash/GNU/POSIX/Linux stuff that is so incredibly good that people will make an effort to widely adopt it. I think this has happened with Meson and CMake. The GNU Autotools stuff is so much worse than Meson and CMake that vast numbers of projects are making the large effort to switch over to one of them.
        Right. We can hope. I doubt it will happen soon for the same reason that C++ isn't going anywhere.

        Originally posted by cybertraveler View Post
        Are you sure that being Open Source is enough? I'm not.

        The controller of a dominant implementation of software can influence all forks for the same reason that the POSIX environment hasn't been replaced even though there are likely technically and ergonomically superior alternatives. If PowerShell did get very popular and people started writing alternative implementations or creating forks of it, the Microsoft implementation would remain the defacto rolling-standard for as long as Microsoft had the plurality of the PowerShell implementation market. If Microsoft changed something or added something that people generally didn't like, all the forks and alternative implementations would likely implement these things just to remain compatible. There would be a limit to what people would accept, but the process of finding that limit and then eventually departing from Microsoft would be long, stressful and messy: as has been the case with Internet Explorer.

        A friendly company with care for communities, culture and people in general might not use their plurality control of a market to push features people generally didn't want. Microsoft are historically not friendly at all. There are some signs that Microsoft's internal culture is changing, but I think it is wise for people to be highly sceptical of Microsoft considering their track record and how much damage they have already done.

        There are many stories and allegories of snakes that are friendly at first. They whisper nice things in your ear and help out. You start to believe that the snake is friendly and empathetic like yourself. But once you let the snake in your life and you give it trust, it strikes while you are vulnerable and bites you getting exactly what it wanted from the start.

        Microsoft: Fool me once: shame on you. Fool me twice: shame on me. Fool me for the TENTH TIME RUNNING... OK FINE! I've learned my lesson
        I understand your argument there but I don't think it holds with open source software. When Microsoft did standards-incompatible things with Internet Explorer or their Java ripoff Visual J++, the world had to play ball because nobody had the legal right to fork IE or J++. That will never be true here. There is an equal risk that a fork of PowerShell that does things Microsoft would not prefer becomes the most widely used version of the tool, and there is nothing they can do about it.

        In general, in the early 2000s I hated Microsoft and loved some other companies, including Google. Today I have shifted my perspective. The problem is not individual people or corporate culture at individual companies. The problem is market position. When a company is a minority player in a market it's in their interest to support standards and standards compliance to improve their own ability to compete. When a company is the dominant player in a market it's in their interest to move away from open standards to lock in customers.

        This holds true everywhere. When IE dominated the market, Microsoft broke standards compliance on purpose to maintain their position. Once IE lost its dominant position, Microsoft put tremendous effort into making the progressive Edge browser standards-compliant. For a few years around 2015 or so, Microsoft Edge had higher scores on HTML feature compliance than Chromium, Chrome, or Firefox. For the 1990s and 2000s Microsoft was, of course, heavily oriented towards promoting native Windows applications. Now that Windows Mobile is an insignificant player in the massive mobile device market, Microsoft is a champion of cross-platform Progressive Web Applications (PWAs) for the sake of making Windows Mobile more attractive to buyers despite the larger iOS and Android application markets.

        Look at Google and Android. The Android code is open source but the Android name is trademarked, and if you want to use the name you have to put the Google application store and applications on your product. A few years ago Microsoft contacted Google and asked for access to Youtube APIs so they could build a competitive native Youtube application for Windows Phone. Google refused. Microsoft tried to pay Google for the access. Google refused. Microsoft wrote an application that scraped Youtube pages and displayed Youtube videos in a Windows Phone native application, preserving all ads and cookies and so forth. Google blocked that access and intentionally provided slower, less responsive Youtube web pages to Windows Phone browsers.

        And of course, Amazon is the king of web services right now and while you can rent vanilla servers they promote the hell out of their proprietary data tools, storage options, database-as-a-service, platform-as-a-service offerings, and software-defined-networking options. They own the biggest piece of the market, they want to lock customers in.

        So don't look at the company. Look at the market position. That's a better indicator of whether they'll support open standards.

        Originally posted by cybertraveler View Post
        Thanks for the link. The syntax does look familiar.

        It seems odd to me that long options are prefixed with a single dash the same way as short options. This means that the options -F -l -i -p could not be contracted down to -Flip without risking ambiguity when there is a long option named "-Flip". I don't know how program designers are supposed to avoid these collisions. Perhaps upper case short options are not permitted. Or perhaps they just don't care because the chance of a collision is probably quite low. Feels nasty though. The GNU project solved this problem quite nicely with their solution.

        I also noticed that the position of the options for sls does seem to vary throughout the article. For example, the following are found in the article:
        Code:
        sls -n go .\demo_text.txt
        sls this .\demo_text.txt -ca
        Good point, though maybe the placement of "-n" and "-ca" are the same across multiple commands. Or maybe not, and the tool isn't as consistent as I thought.

        Comment


        • #34
          Originally posted by Michael_S View Post
          ...

          So don't look at the company. Look at the market position. That's a better indicator of whether they'll support open standards.
          I'll think about that, thanks.

          Comment


          • #35
            just because they open sourced something doesnt mean its not part of their EEE strategy. Seems like "embracing" to me. Just like their open sourcing of their office document format.

            Comment

            Working...
            X