The input box should handle binary streams, buffered input, file contents and
editing line with special program.
All this can be done by running another st with vim f.ex
This sounds to me like replicating work.. A microwm.. 2 terminals.. Keyboard
handling for switching modes.. We will make then
On Fri, May 20, 2011 at 2:46 PM, Benjamin R. Haskell
wrote:
> Why would you escape the asterisks here? It's not looking for literal
> asterisks.
Oops, you wouldn't. But, knowing the output format of history, I'd
change the asterisks to \+, which does require escaping in sed, which
is the half of
On Fri, 20 May 2011, Andrew Hills wrote:
On Fri, May 20, 2011 at 2:06 PM, Kurt H Maier wrote:
> [...] wouldn't something akin to
>
> history | sort -r | sed '1d; s/^[ \t]*[0-9]*[ \t]*//'
>
> work just as well?
Didn't realize `sed` didn't have \d, but why [ \t] instead of \s?
[...] (Don't
On Fri, May 20, 2011 at 2:22 PM, Kurt H Maier wrote:
> I just pasted the output of TermKit.
Something tells me to suspect that this is untrue.
--Andrew Hills
On Fri, May 20, 2011 at 2:21 PM, Andrew Hills wrote:
> (Don't forget to escape your asterisks in sed.)
I just pasted the output of TermKit.
--
# Kurt H Maier
On Fri, May 20, 2011 at 2:06 PM, Kurt H Maier wrote:
> Any reason not to sort(1) them before you feed them to perl? And
> don't get me wrong: perl is my favorite language, but wouldn't
> something akin to
>
> history | sort -r | sed '1d; s/^[ \t]*[0-9]*[ \t]*//'
>
> work just as well?
Yes. When
On Fri, 20 May 2011, Kurt H Maier wrote:
Any reason not to sort(1) them before you feed them to perl? And
don't get me wrong: perl is my favorite language, but wouldn't
something akin to
history | sort -r | sed '1d; s/^[ \t]*[0-9]*[ \t]*//'
work just as well?
I would've changed it to use
On Fri, May 20, 2011 at 1:42 PM, Andrew Hills wrote:
> Not supported by default on Solaris 5.8, Solaris 5.10, RHEL 4(NU7),
> RHEL 5.6, or Arch Linux (updated an hour ago). According to [0], only
> BSD tail has the reverse option.
Any reason not to sort(1) them before you feed them to perl? And
On Fri, May 20, 2011 at 1:23 PM, Benjamin R. Haskell
wrote:
> Anyone know what `tail`s support '-r' ( == reverse? )?
Not supported by default on Solaris 5.8, Solaris 5.10, RHEL 4(NU7),
RHEL 5.6, or Arch Linux (updated an hour ago). According to [0], only
BSD tail has the reverse option.
0. http:
On Fri, 20 May 2011, Andrew Hills wrote:
Thanks for the Perl-readability tip.
No prob.
On Fri, May 20, 2011 at 12:58 PM, Benjamin R. Haskell wrote:
Don't have `tac` installed? (I think it's in linux-utils or
core-utils, but maybe it's linux- and/or GNU-centric.)
I do most of my work on
Thanks for the Perl-readability tip.
On Fri, May 20, 2011 at 12:58 PM, Benjamin R. Haskell
wrote:
> Don't have `tac` installed? (I think it's in linux-utils or core-utils, but
> maybe it's linux- and/or GNU-centric.)
I do most of my work on Solaris, and it's not really worth the effort
to insta
On Fri, 20 May 2011, Andrew Hills wrote:
On Fri, May 20, 2011 at 12:16 PM, Suraj N. Kurapati wrote:
history | xmessage -file - &
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i>=0;$i--){print $o[$i];}' | dmenu -b
On Fri, May 20, 2011 at 12:47 PM, Bjartur Thorlacius
wrote:
> I'm sorry for my total lack of 1337ness, but what does the perl part do?
Strips the numbers off the start of each line, reverses the order (for
most recent first), and skips the first (last) entry (which is the
command you typed to bri
On 5/20/11, Andrew Hills wrote:
> I keep this ugly mess around in for convenience:
>
> h()
> {
> `history | perl -e 'while(){s/\s+\d+\s+//;push
> @o,$_;}for($i=$#o-1;$i>=0;$i--){print $o[$i];}' | dmenu -b`
> }
I'm sorry for my total lack of 1337ness, but what does the perl part do?
On 20 May 2011 17:24, Suraj N. Kurapati wrote:
> Use /dev/tty to "draw" to the terminal independently of std streams:
>
> date | sh -c 'read; echo "$REPLY" > /dev/tty' >/dev/null
Your graphics look suspiciously like text.
(I think you missed the point.)
cls
On Fri, May 20, 2011 at 12:16 PM, Suraj N. Kurapati wrote:
> history | xmessage -file - &
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i>=0;$i--){print $o[$i];}' | dmenu -b`
}
--Andrew Hills
On Fri 20 May 2011 01:26:56 PM PDT, Connor Lane Smith wrote:
> allow commands to draw directly to the terminal if they wanted. So
> the standard input / output piping system would remain unchanged,
Use /dev/tty to "draw" to the terminal independently of std streams:
date | sh -c 'read; echo "$R
On Fri 20 May 2011 12:51:35 PM PDT, David Tweed wrote:
> At the very least, it would be very productive to [... have] the
> _option_ for shell history to pop up in another window, rather
> than _only_ being available as a command output, so that it
> scrolls other stuff you've been doing off the sc
2011/5/20 Hadrian Węgrzynowski :
> Sometimes I would like to display some graphics inside terminal window.
> We could draw directly in terminal's window or place graphics inline
> with text. I would prefer second method.
I think the way I described it in my first email was a little
confusing. As I
On Fri, May 20, 2011 at 03:19:00PM +0100, Connor Lane Smith wrote:
> On 20 May 2011 14:54, Kurt H Maier wrote:
> > I don't understand why. If you want stderr to be combined into
> > stdout, suffix 2>&1 to your command. By default, I think different
> > filehandles should land in different output
Sometimes I would like to display some graphics inside terminal window.
We could draw directly in terminal's window or place graphics inline
with text. I would prefer second method.
One of the key features of text terminals is monospaced font - that
makes everything easier to align and easier to co
On Fri, May 20, 2011 at 10:19 AM, Connor Lane Smith wrote:
> I just think the stdout and stderr ought to be visible at the same
> time. Or perhaps it would suffice to show stderr above stdout, or
> automatically switch, or something.
I agree stderr ought to be visible. I picture either a smaller
On Fri, 20 May 2011 15:19:00 +0100
Connor Lane Smith wrote:
> On 20 May 2011 14:54, Kurt H Maier wrote:
> > I don't understand why. If you want stderr to be combined into
> > stdout, suffix 2>&1 to your command. By default, I think different
> > filehandles should land in different outputs.
>
On 20 May 2011 14:54, Kurt H Maier wrote:
> I don't understand why. If you want stderr to be combined into
> stdout, suffix 2>&1 to your command. By default, I think different
> filehandles should land in different outputs.
I just think the stdout and stderr ought to be visible at the same
time
On Fri, May 20, 2011 at 9:40 AM, Connor Lane Smith wrote:
> I suppose that could be a useful interface, so long as it was clear
> which commands are associated with which output. Otherwise stdout
> could get a little messy. Also, by default stdout and stderr ought to
> be combined, perhaps with st
On Fri, 20 May 2011 14:40:39 +0100
Connor Lane Smith wrote:
> On 20 May 2011 14:27, Dieter Plaetinck wrote:
> > I think a fd to write something to like "here's an image, please
> > render it somewhere" is better than cls's suggestion of having apps
> > directly write to the terminal. I think
On 20 May 2011 14:17, Kurt H Maier wrote:
> I've never understood why there isn't a terminal with one window per
> filehandle. Something like sam's interface, but the top window would
> just hold stdin and the bottom window should toggle between stdout and
> stderr.
I suppose that could be a use
How hard would it be to have fd 3 or 4 be a mmap'able image of the
window (like /dev/fb) && would this suck less?
On 20 May 2011 09:27, Dieter Plaetinck wrote:
> [...]
> 6)non sucky rendering. I think applications should be able to have
> pixel-precise control of what the output should be (othe
On Fri, 20 May 2011 12:51:35 +0100
David Tweed wrote:
> it always depresses me that it's
> kind of taken as a virtue that the interactive shell and the terminal
> are know almost nothing about each other (at least for almost all
> modern computing devices, I can see if you genuinely are using a
>
+ Connor Lane Smith ---+
>
> However, if the command would like it could communicate directly to
> the term and say "show this diagram", or whatever. The term would
> basically be an ever-downward-scrolling canvas, which shows mostly
> text but may o
On Fri, May 20, 2011 at 1:26 PM, Connor Lane Smith wrote:
> fwiw, I agree. TermKit appears to be a very glossy turd, but there are
> certainly outstanding issues in our terminals, which is why in Plan 9
> they tried to fix them by pairing a plaintext-only Rio term with
> graphical windows which a
On Fri, May 20, 2011 at 9:01 AM, Aurélien Aptel
wrote:
> rxvt implements basic drawing primitives via escape codes[1]. It's
> disabled at compile time by default but you can find some poc in the
> source distribution that plots stuff. I think it has been dropped in
> urxvt. It's ok for very simple
On Fri, May 20, 2011 at 2:26 PM, Connor Lane Smith wrote:
> I think the way to solve this problem is not to add structure to pipes
> (which tend to be simple to use *because* they have no real
> structure), but to allow commands to draw directly to the terminal if
> they wanted. So the standard in
Hey,
On 20 May 2011 12:51, David Tweed wrote:
> Certainly the general implementation, the language and the
> architecture do seem nasty. OTOH, it always depresses me that it's
> kind of taken as a virtue that the interactive shell and the terminal
> are know almost nothing about each other
fwiw,
On Fri, May 20, 2011 at 10:06 AM, Nick wrote:
> On Fri, May 20, 2011 at 12:23:39AM +0200, hiro wrote:
>> https://github.com/unconed/TermKit
>>
>> no comment, only sorry.
>
> indeed. i read about it yesterday. makes me want to vomit.
>
>
Certainly the general implementation, the language and the
ar
On Fri, May 20, 2011 at 12:23:39AM +0200, hiro wrote:
> https://github.com/unconed/TermKit
>
> no comment, only sorry.
indeed. i read about it yesterday. makes me want to vomit.
On 05-20 00:23, hiro wrote:
https://github.com/unconed/TermKit
Idea: http://acko.net/blog/on-termkit
Videos: http://acko.net/blog/i-put-a-spell-on-you
--
ilf
Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastatu
37 matches
Mail list logo
