Terminal does not continue running when switching to other apps

[GoogleCodeExporter]

1. Open Terminal, and type something
2. Click the 'home' button
3. Open Terminal again.  A fresh shell will be running.

It would be very nice to start terminal and see the previous session.  
Currently responding to an SMS or receiving a phone call will 
terminate what you are doing.  That is very bad.

One possible (but kinda hacky) solution is to add the ability to configure a 
command to be run when terminal starts, and have it 
run a script to launch 'screen' with the proper arguments.  Effectively this 
would have the same result as keeping the application 
running the whole time.  The biggest problem with this however is that it 
basically means that you can not use screen inside the 
terminal. The upshot though is that even if Terminal.app crashes the session 
will keep running.

Perhaps a modified version of screen could be included with Terminal.app that 
uses different key strokes, and give Terminal.app 
buttons or menu items to use those key strokes.  This would easily give 
features such as multiple tabs, and such, and still allow 
running screen within a session because that would use the original screen 
keystrokes.

Original issue reported on code.google.com by britr...@gmail.com on 5 Aug 2007 at 3:30

[GoogleCodeExporter]

MobileSafari and other apps stay persistent, though. It should be do-able 
without
being hackish.

Original comment by timd...@gmail.com on 5 Aug 2007 at 6:39

[GoogleCodeExporter]

Yes it should be possible without being hackish, but if that proves difficult 
then screen could be a nice quick 
fix.  It would of course be better to do it right.

Original comment by britr...@gmail.com on 5 Aug 2007 at 7:19

[GoogleCodeExporter]

Actually, I wouldn't even call using screen "hackish".  It already provides an 
incredible set of features for 
multiplexing one VTY.  Why not use it instead of recoding most of its 
functionality?

Original comment by RobertDy...@gmail.com on 5 Aug 2007 at 7:48

[GoogleCodeExporter]

That was my original thought.  With very little work we could have many cool 
features, such as persistent 
sessions, tabs, etc.

It will work well and be much easier to implement than doing it the "right way".

Original comment by britr...@gmail.com on 5 Aug 2007 at 8:05

[GoogleCodeExporter]

My point is what makes using screen not the "right way"?  The functionality is 
already there.  It would basically 
give MobileTerminal session persistence, tabs, etc. "for free" similar to how 
Core Data provides undo 
functionality and saving "for free".

Original comment by RobertDy...@gmail.com on 5 Aug 2007 at 11:28

[GoogleCodeExporter]

Screen would be nice.  We'd need to be able to send control keys, or perhaps 
have buttons at the bottom of the 
screen to be able to disconnect from sessions etc.

Original comment by simonrsp...@gmail.com on 6 Aug 2007 at 12:03

[GoogleCodeExporter]

yeah I'm pretty convinced that screen is the way to go.  I'm pretty sure that 
you can specify a key other than 
contol-a to use with a command line argument.  This would make for a very easy 
method of resuming 
sessions and creating "tabs".

So at startup simply run "screen -dr mobileterminal" to reconnect to the 
session, and if that fails (returns non 
0) then run "screen -S mobileterminal" instead to start a new session instead.

Then adding a plus button to create a new screen another a button for next and 
prev would be all we need.  
I'd be very happy with that.

This all assumes we have vt100 soon and that we can build screen for the iPhone 
(should be easy)

Original comment by britr...@gmail.com on 6 Aug 2007 at 12:24

[GoogleCodeExporter]

I found the argument to screen to switch the control character.

-e^Bb

That will change the control character to control b instead of control a.  I 
think we should find some key that is 
very hard to actually type in real life, and use that.  The nice upside to 
using something other than control-a is 
that screen can still be used inside terminal.app.  That will be VERY nice for 
connection to remote server and 
being able to use screen there with the normal key strokes, but still get the 
extra functionality in mobile 
terminal.

I haven't looked at the code used to launch the keyboard yet, but I'm really 
wondering what kind of control we 
have over the keyboard.  It is obvious that the keyboard can be changed, if you 
look at things like address 
entry in mobile safari.  Do we have full control over that though?  Or are 
there simply a handful of modes.

If we had full control over it then it would be very nice to add a few extra 
keys, possibly by making space bar 
smaller, or something like that.

Another option that might be nice for the terminal would be to have transparent 
buttons on the top portion of 
the screen for various common tasks.  That way the pixels would still be useful 
for showing text, but touch 
there would be useful for an action.  In fact, we could even simply define 
areas to be common buttons, and 
not make it visible at all.  For example, the top left corner could be 
'previous window' and the top right could 
be 'next window' and the top center could be 'new window', and bottom left 
could be control, bottom right 
could switch the keyboard to arrow keys, etc.

There is a lot of cool stuff we can do here.  I really think that before long 
we can have the best mobile phone 
terminal application ever made.

Original comment by britr...@gmail.com on 6 Aug 2007 at 12:44

[GoogleCodeExporter]

Transparent buttons might be nice, but I would *really* prefer them to be 
visible.  I like to be able to see things 
that I'm about to trigger.  Maybe a good thing to stick into a Preference 
system.

The ideal system to me would be something like Safari's tabs.  Press a special 
button to go into tab switching 
mode, then flick through the list to find the one you want.  Might not work 
that well, since terminals tend to 
look pretty similar, so the visual cues for which is which aren't as big as 
with websites.  Still, it's a decent 
method of displaying tabs on a small screen and the behavior is already 
established.

Maybe rather than a set of transparent buttons, a single, screen-wide 
transparent button that brings up a 
visible bar to change tabs and so forth.  Kind of like in Photos.

Original comment by RobertDy...@gmail.com on 6 Aug 2007 at 4:31

[GoogleCodeExporter]

Yeah, perhaps tapping on the screen should show a button bar, similar to the 
way photos work.  One button 
could be used to show tabs like safari, and of course there are many other 
things that could be included.

Since the small views will all look the same perhaps the thumbnail view should 
show cropped view instead of 
a stretched view.  Perhaps the bottom left corner of the screen.  This would 
generally be a lot more useful 
than a scaled image of the terminal where you can't read anything.  Maybe even 
do some simple processing to 
determine the busiest portion of the screen and show that.

Also, screen allows naming of tabs.  Asking for a name when creating a new 
screen, and showing that as a 
title would be useful as well.

Original comment by britr...@gmail.com on 6 Aug 2007 at 5:23

[GoogleCodeExporter]

What if we use screen(1) to handle this? run screen -D -RR on terminal startup 
and
then we don't have to worry about it

To do it myself, I do this --

[ "$TERM" = "network" ] && (export TERM=xterm-color;screen -D -RR)

in my .zshrc (I use zsh for my main shell)

This seems pretty reliable, and once we get naim or centericq or bitchx or 
irssi or
pidgin-text going, we'll be able to use them easily this way

Of course we need arrow-keys too

Original comment by LivingLa...@gmail.com on 15 Aug 2007 at 1:41

[GoogleCodeExporter]

Does anyone have a copy of screen running? I built it from source with a 
PPC-hosted toolchain, but when I run 
screen I only receive "permission denied". It's not a permissions issue - chmod 
755 doesn't help - but I'm 
guessing an incorrect TTY. 

I'm very interested as my office requires us to ssh to a specific machine to 
enable general wireless use - and 
without screen, I can have ssh or anything else, not both. 

Original comment by aber...@zathras.net on 23 Aug 2007 at 2:51

[GoogleCodeExporter]

What directory did you put your copy of screen in?  I tried to run something I
compiled in /var/root and got the permission denied error but it worked after I 
moved
it to /bin.

Original comment by vince...@gmail.com on 28 Aug 2007 at 7:44

[GoogleCodeExporter]

Yeah, I'm an idiot. 

I was executing screen from the local directory (./screen from /var/root), but 
copying it to /bin gets me farther. 
The new error is "mkfifo /tmp/screens/S-root/86.ttyp0.Corwin failed". The files 
are there, but they're definitely 
not fifos. 

Original comment by aber...@gmail.com on 31 Aug 2007 at 3:30

[GoogleCodeExporter]

I think keeping the previous terminal session should definitely be the default 
behavior.

That said, I don't know if we have found a way (yet) to keep keyboard focus when
resuming the application.  Moved to high priority.

Original comment by allen.po...@gmail.com on 21 Sep 2007 at 12:55

• Changed state: Accepted
• Added labels: Priority-High, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Yes, please try to fix this problem ASAP. This is the only thing that prevents 
me and hundreds others from 
accessing the Internet on my campus. I truly appreciate your efforts and I 
thank you in advance for getting this 
done.

Original comment by anbad...@gmail.com on 1 Oct 2007 at 1:44

[GoogleCodeExporter]

Is anyone able to get screen to work correctly ?
I run "screen bash" and check the processes with ps and see it running just 
fine.
I disconnected mobile terminal with the belly button, come back in and try to 
"screen -r" and it won't connect, 
although a screen process is running, but it doesn't show that it's running 
bash.

I use screen a lot on my other unix boxes this way and have no trouble.  

Anyone have a know working sequence to get something retained during mobile 
terminal running, quit and 
running again ?

Original comment by simonrsp...@gmail.com on 1 Oct 2007 at 11:52

[GoogleCodeExporter]

MobileTerminal now supports suspend and resume as of revision 199, and it will 
be
included in the next binary release (whenever that happens).  I am closing this 
bug,
but feel free to open it if there are any problems (or mark it as verified if 
you
like it)

Original comment by allen.po...@gmail.com on 2 Oct 2007 at 2:35

• Changed state: Fixed