Thinking about a new shell
in [Shell]
|
Prev: Regular Expression
Next: Symbol for "not" within []
From: patata on 7 Aug 2010 06:58 On Aug 7, 12:27 pm, Eric <e...(a)deptj.eu> wrote: > On 2010-08-07, patata <qpat...(a)gmail.com> wrote: > > > So you want to write a new shell, and rewrite every single non-gui command > (each of which is a separate program) to include generators and parsers > for some format and work out how so many disparate types of information > will be represented in that format. Good luck! > Yes, this is one of the problems of this approach. But even thinking about the mandatory reuse of existing commands, and if no other trick is found, it could be better to have a single and public available librarian of parsers (with automatic download as shell feature?) that continue in the current way, where each user mades its own parsers, user after user, day after day (look how many queries in this group are about how to do it for some case). > BTW, if you think XML is a binary format (even if you put "binary" in > quotes), you are seriously deluded. And TLV is only a concept, you'd > have to define lots of rules for how that would be used too. > I agree, XML is structured but no binary (and not one of my favorites). A TLV variant is mades easy to read information, and a few more complex to write it. A structured ("C", java, ... like) syntax, who uses text blocks enclosed by "{" "}", comma separated lists, etc is another possibility. Thanks for your collaboration.
From: Janis Papanagnou on 7 Aug 2010 07:10 On 07/08/10 12:01, patata wrote: > Hello, > > First, let me to thank all people involved in this group for your > continuous support, that saves me a lot of troubles. > > After years as user of shells, several problems with all them appears > always. Some examples of these problems are: > > lack of ortogonality (an example, a command "ls" with some sorting > rule): > "ls" has some intrinsic sort capabilities, but not very complete. ....which is a Good Thing. Sorting is a function interesting for many of those hundreds and thousands of utilities in the Unix environment. Duplicating that (and/or other) function(s) is mostly a Bad Thing. > In the same way, lots of commands have several sorting capabilities, > always limited and duplicated to the others > "sort" command could have a complete set of capabilities, but then it > must parse the "ls" output, something not always easy. > It seems we have not a shell who allows a powerful "sort" command or > librarian to merge easily with any "data provider" (ls). Well, the existing sort(1) command *is* extremely powerful. And the sort command is luckily also indepentent from the shell and can thus be used in any other Unix tool context as well. Your idea of a "sort librarian" is not bad. But there's a simpler and thus better approach. Let the commands produce well defined (textual and simply parsable) output using format specifiers, as in ps with ps -o , then you can use the standard sort command and all the existing column and row extraction tools easily. Say, with you ls example, you want to sort by time; don't use ls -t rather use the (hypothetical) ls -o "%t %n" | sort ... > Too much text oriented: > Most commands tries to provide an output in a nice textual, human > readable form. That is good if the command is used in a standalone > way, but bad when this output must be used by the next command. A standard textual form is what makes the Unix environment so powerful. With the given text interface, you can combine all sorts of tools in a orthogonal way; every tool does its specific task and can be combined with any other tool. The Unix tool-box philosophy isn't bad, really, rather it's very flexible and powerful. > I'm wondering if it is not better to have "binary" input/output for > commands (TLV, XML or something similar). Why pass binary information; there's really no necessity it seems.[*] (And, BTW, XML is not binary; rather it's bloated text.) > The shell will be the > responsable of convert this binary data from/to human readable at the > start/end of the pipelines. (I can't claim to have detailed knowledge about Microsoft's new shell, but could it be that you want to go that way (for whatever reason)?) > Thinking on how to solve these and similar problems, or even in the > development of a new shell variant, any comment, suggestion or link > about these subjects is welcome. I wouldn't invent another shell, rather fix the inflexibility of output specifications in those commands where it is still missing. I gave an example with ps -o which made its way from AIX to Linux[**], there are other commands like date +%format and I'd continue the way with such format specifiers[***] for other tools where they are missing and where they seem appropriate. One advantage of that is that you don't need to re-invent everything, starting from the shell and continuing with all tools. Another advantage is that I'd like to define myself what the tools shall display, so I'd like the format specifiers anyway; for tailored textual output as well as for the automation of data processing. Janis [*] Strictly speaking; technically we already can already pass binary information between commands. But I presume you want to pass everything on attributes on binary level and extract just what you need. If that's the case you probably will get a performance issue with your approach, depending on how many attributes any specific tool will be able to emit. [**] And probably other platforms as well. It might even be in POSIX? [***] It would even be good to have a standard option letter for that, but given the historical uncontrolled growth of options I don't see a chance here. Janis > > Kind regards.
From: patata on 7 Aug 2010 07:48 On Aug 7, 1:10 pm, Janis Papanagnou <janis_papanag...(a)hotmail.com> wrote: > On 07/08/10 12:01, patata wrote: > > > lack of ortogonality (an example, a command "ls" with some sorting > > rule): > > "ls" has some intrinsic sort capabilities, but not very complete. > > ...which is a Good Thing. Sorting is a function interesting for many > of those hundreds and thousands of utilities in the Unix environment. > Duplicating that (and/or other) function(s) is mostly a Bad Thing. > > > In the same way, lots of commands have several sorting capabilities, > > always limited and duplicated to the others > > "sort" command could have a complete set of capabilities, but then it > > must parse the "ls" output, something not always easy. > > It seems we have not a shell who allows a powerful "sort" command or > > librarian to merge easily with any "data provider" (ls). > > Well, the existing sort(1) command *is* extremely powerful. And the > sort command is luckily also indepentent from the shell and can thus > be used in any other Unix tool context as well. > I agree, it is better the orthogonal approach: a powerful "sort" command instead of sort capabilities in the other ones. But, if currently commands like "ls" or "ps" have their own sort capabilities is because it is not easy to merge them with the standard sort. This is the open point. > > Let the commands produce well defined (textual and simply parsable) > output using format specifiers, as in ps with ps -o , then you can > use the standard sort command and all the existing column and row > extraction tools easily. > > Say, with you ls example, you want to sort by time; don't use ls -t > rather use the (hypothetical) ls -o "%t %n" | sort ... > > [...] > [***] It would even be good to have a standard option letter for that, > but given the historical uncontrolled growth of options I don't see a > chance here. > Here is where the shell extension could help us. Instead of modify existing commands, add a formatting capability to the shell. This extension will wrap the command and format their output in the standard syntax. Something like: reformat ls ...... | sort ... or event a sugar syntax: @ls ... | sort The "standard" syntax could be, like in your examples, a tab separated one, where each item is in one single line at fields are splited by tabs. In this way the output is standard, formatted and textual (however, in more complex cases, it could be necessary to group data items with something like {}). Thanks a lot for your collaboration.
From: News123 on 7 Aug 2010 08:04 On 08/07/2010 12:01 PM, patata wrote: > Hello, > > First, let me to thank all people involved in this group for your > continuous support, that saves me a lot of troubles. > > After years as user of shells, several problems with all them appears > always. Some examples of these problems are: > > lack of ortogonality (an example, a command "ls" with some sorting > rule): > "ls" has some intrinsic sort capabilities, but not very complete. In > the same way, lots of commands have several sorting capabilities, > always limited and duplicated to the others > "sort" command could have a complete set of capabilities, but then it > must parse the "ls" output, something not always easy. > It seems we have not a shell who allows a powerful "sort" command or > librarian to merge easily with any "data provider" (ls). > .. . . You seem to confuse two things. )or the subject line is not well chosen) A shell is used to glue together existing commands. Witing a new shell will and should not change the behaviour of the underlying OS'es commands. What you propose is not a new shell, but an entire new set of commands and a new shell. It seems you want to re-invent unix/linux but differently. Or alternatively: Don't use a shell and the OS-commands at all. Just write a library for perl / python which re-implements the basic commands like ls / sort in a way that you like and decide on a new format exchanging the date between all your new commands. Then write your shell scripts in this language or os a simple CLI version of it as a front end.
From: patata on 7 Aug 2010 08:15
On Aug 7, 1:04 pm, News123 <news1...(a)free.fr> wrote: > On 08/07/2010 12:01 PM, patata wrote: > > > Hello, > > > First, let me to thank all people involved in this group for your > > continuous support, that saves me a lot of troubles. > > > After years as user of shells, several problems with all them appears > > always. Some examples of these problems are: > > > lack of ortogonality (an example, a command "ls" with some sorting > > rule): > > "ls" has some intrinsic sort capabilities, but not very complete. In > > the same way, lots of commands have several sorting capabilities, > > always limited and duplicated to the others > > "sort" command could have a complete set of capabilities, but then it > > must parse the "ls" output, something not always easy. > > It seems we have not a shell who allows a powerful "sort" command or > > librarian to merge easily with any "data provider" (ls). > > . . . > > You seem to confuse two things. )or the subject line is not well chosen) > > A shell is used to glue together existing commands. > > Witing a new shell will and should not change the behaviour of the > underlying OS'es commands. > > What you propose is not a new shell, but an entire new set of commands > and a new shell. > > It seems you want to re-invent unix/linux but differently. > > Or alternatively: > > Don't use a shell and the OS-commands at all. > > Just write a library for perl / python which re-implements the basic > commands like ls / sort in a way that you like and decide on a new > format exchanging the date between all your new commands. > > Then write your shell scripts in this language or os a simple CLI > version of it as a front end. Thanks for your comment. It seems that all post agrees that the way to allow better orthogonality and command integration is an standard format for data streams (?). Like you say, it is not possible to rewrite all standard unix commands. Please, see at the post of Mr.Papanagnou and following about alternatives and how a shell improvement could help. About use perl or python instead of Posix shells, all us we known that in lots of cases it is still better to relay at shell layer. Kind regards. |