Thinking about a new shell
in [Shell]
|
Prev: Regular Expression
Next: Symbol for "not" within []
From: patata on 7 Aug 2010 06:01 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). 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. I'm wondering if it is not better to have "binary" input/output for commands (TLV, XML or something similar). The shell will be the responsable of convert this binary data from/to human readable at the start/end of the pipelines. 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. Kind regards.
From: Kees Nuyt on 7 Aug 2010 06:37 On Sat, 7 Aug 2010 03:01:20 -0700 (PDT), patata <qpatata(a)gmail.com> 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). > >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. >I'm wondering if it is not better to have "binary" input/output for >commands (TLV, XML or something similar). The shell will be the >responsable of convert this binary data from/to human readable at the >start/end of the pipelines. > >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. That's exactly what Microsoft Powershell implements, it passes structured objects through the pipes. Very powerful for system administration tasks, because Powershell can query almost everything from the underlying operating system. ACL's apply and scripts can be signed. The main disadvantages are: - you have to know the names of the attributes to access them. - scripts are very wordy (and that would be hard to avoid) Best regards, -- ( Kees Nuyt ) c[_]
From: Eric on 7 Aug 2010 06:27 On 2010-08-07, patata <qpatata(a)gmail.com> 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). > > 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. > I'm wondering if it is not better to have "binary" input/output for > commands (TLV, XML or something similar). The shell will be the > responsable of convert this binary data from/to human readable at the > start/end of the pipelines. > > 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. > > Kind regards. 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! 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. E.
From: Mart Frauenlob on 7 Aug 2010 06:43 On 07.08.2010 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. 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). > > 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. > I'm wondering if it is not better to have "binary" input/output for > commands (TLV, XML or something similar). The shell will be the > responsable of convert this binary data from/to human readable at the > start/end of the pipelines. > > 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. > > Kind regards. M$ did some like that with powershell: http://en.wikipedia.org/wiki/Windows_PowerShell
From: patata on 7 Aug 2010 06:48
On Aug 7, 12:43 pm, Mart Frauenlob <VornamePunktNachn...(a)chello.at> wrote: > On 07.08.2010 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. 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). > > > 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. > > I'm wondering if it is not better to have "binary" input/output for > > commands (TLV, XML or something similar). The shell will be the > > responsable of convert this binary data from/to human readable at the > > start/end of the pipelines. > > > 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. > > > Kind regards. > > M$ did some like that with powershell:http://en.wikipedia.org/wiki/Windows_PowerShell Thanks to you and Mr.Nuyt for this link, I will review it. |