Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > Secure Shell

Reply
 
Thread Tools Display Modes
  #1  
Old 03-22-2010, 01:20 PM
tbessie tbessie is offline
Registered User
 
Join Date: Mar 2010
Posts: 8
How to make SecureCRT *not* close when last tab is closed?

Hello there...

So I want tabs to close when the session is closed, but I don't want SecureCRT to exit when that last tab/session is closed. I don't see a setting for this anywhere, however.

Is this doable?

- Tim
Reply With Quote
  #2  
Old 03-22-2010, 02:04 PM
rtb rtb is offline
VanDyke Technical Support
 
Join Date: Aug 2008
Posts: 4,306
Hi Tim,

It is not currently possible to close the last tab in SecureCRT. As this is the case, if you can describe in detail what steps you are manually taking, we may be able to help you find a solution to the problem.

Would you post the exact steps you are taking which result in SecureCRT closing?

If you are using a script, would you post the script you are running?
__________________
--Todd

VanDyke Software
Technical Support
support@vandyke.com
505-332-5730
Reply With Quote
  #3  
Old 03-22-2010, 04:47 PM
tbessie tbessie is offline
Registered User
 
Join Date: Mar 2010
Posts: 8
Quote:
Originally Posted by rtb
Hi Tim,

It is not currently possible to close the last tab in SecureCRT. As this is the case, if you can describe in detail what steps you are manually taking, we may be able to help you find a solution to the problem.

Would you post the exact steps you are taking which result in SecureCRT closing?

If you are using a script, would you post the script you are running?
Hello rtb...

I'm not using any scripts. The thing is, when SecureCRT starts, there are no tabs open. It seems logical, given that, that you should be able to close the last tab (so that there are no tabs open), and yet SecureCRT not shut down, doesn't it?

The "steps" I'm taking are merely opening a bunch of sessions in tabs, and, as I'm done with each one, logging out of the session (a regular Unix logout). Let's say for argument's sake I've open 5 sessions in tabs, each of which is a connection to 1 group of servers.

Now I want to open connections to a different group of servers... so I log out of all the current sessions, thus closing the tabs (as I've selected Terminal->Close on disconnect). If I close the last tab, SecureCRT itself closes. This means if I want to open the 2nd set of sessions in my example, I'd have to keep one last tab open, open the 2nd set of sessions, then close the last remaining connection to the 1st set of sessions.

This kind of shuffling seems a little silly for a reasonably expensive program.

Why MUST SecureCRT close when the last session tab is closed, if SecureCRT is able to be open when it starts up without any session tabs open?

- Tim
Reply With Quote
  #4  
Old 03-23-2010, 09:58 AM
rtb rtb is offline
VanDyke Technical Support
 
Join Date: Aug 2008
Posts: 4,306
Hi Tim,

I can tell by your wording that you are pretty frustrated by the current behavior you are seeing in SecureCRT. Here's some historical background to help explain SecureCRT's current "Close on disconnect" behavior.

The "Close on disconnect" option existed in SecureCRT since it's early days -- long before SecureCRT had any support for tabs. It was originally implemented as a response to requests from SecureCRT users who wanted the application to close as soon as the underlying ssh/serial/rlogin/telnet/etc. connection was closed.

When support for tabs was implemented in SecureCRT back in mid 2004, it was decided that the existing "Close on disconnect" session option should close the appropriate tab, and ultimately close the application if the last tab was disconnected. This interaction decision helped to maintain consistency in the existing "Close on disconnect" behavior which long time SecureCRT users had come to expect.

Even though we strive to maintain consistent behavior that long-time users have come to expect, it doesn't mean that we can't add an option to modify this behavior. I have created a feature request in our SecureCRT development database to add just such an option. Should a future release of SecureCRT have the ability to close the last tab rather than the entire application on disconnect, we will post to this forum thread. If you would like to be notified directly, please complete and submit the form at the following location:
Submit Feature Request
__________________
--Todd

VanDyke Software
Technical Support
support@vandyke.com
505-332-5730

Last edited by rtb; 03-23-2010 at 12:05 PM.
Reply With Quote
  #5  
Old 03-23-2010, 11:23 PM
tbessie tbessie is offline
Registered User
 
Join Date: Mar 2010
Posts: 8
Quote:
Originally Posted by rtb
Hi Tim,

I can tell by your wording that you are pretty frustrated by the current behavior you are seeing in SecureCRT. Here's some historical background to help explain SecureCRT's current "Close on disconnect" behavior.

The "Close on disconnect" option existed in SecureCRT since it's early days -- long before SecureCRT had any support for tabs. It was originally implemented as a response to requests from SecureCRT users who wanted the application to close as soon as the underlying ssh/serial/rlogin/telnet/etc. connection was closed.

When support for tabs was implemented in SecureCRT back in mid 2004, it was decided that the existing "Close on disconnect" session option should close the appropriate tab, and ultimately close the application if the last tab was disconnected. This interaction decision helped to maintain consistency in the existing "Close on disconnect" behavior which long time SecureCRT users had come to expect.

Even though we strive to maintain consistent behavior that long-time users have come to expect, it doesn't mean that we can't add an option to modify this behavior. I have created a feature request in our SecureCRT development database to add just such an option. Should a future release of SecureCRT have the ability to close the last tab rather than the entire application on disconnect, we will post to this forum thread. If you would like to be notified directly, please complete and submit the form at the following location:
Submit Feature Request
Hi again, Todd...

Thanks for the very complete description of How Things Came To Be. :-) I understand that the history of an app contributes a ton to its current incarnation, and you don't want to add every feature in the book that someone might think is useful, lest your app bloat out of control.

Still, I think the option of not having SecureCRT close on last tab close (as a non-default option, of course, so as to please long-time users) would be a very useful thing, at least given my own usage patterns.

I've been almost entirely a user of Putty all these years, but, not being happy with the available "Tabbed Putty" variants out there, decided to buy SecureCRT, especially given my last few roles that have added server administration to my regular programming duties - connections to dozens of servers begs for the use of tabbed windows. :-)

In any case, I hope it's a feature you add sooner rather than later. I can work around it, of course, using multiple SecureCRT windows, but it would be great if I didn't need to do that.

Thanks again for your explanation.

- Tim
Reply With Quote
  #6  
Old 03-24-2010, 09:31 AM
rtb rtb is offline
VanDyke Technical Support
 
Join Date: Aug 2008
Posts: 4,306
Hi Tim,

I am glad that I could help explain SecureCRT's current behavior. We will post to this forum thread if a future release of SecureCRT has the ability to modify the way that the last tab is closed.
__________________
--Todd

VanDyke Software
Technical Support
support@vandyke.com
505-332-5730
Reply With Quote
  #7  
Old 03-24-2010, 11:50 AM
tbessie tbessie is offline
Registered User
 
Join Date: Mar 2010
Posts: 8
Quote:
Originally Posted by rtb
Hi Tim,

I am glad that I could help explain SecureCRT's current behavior. We will post to this forum thread if a future release of SecureCRT has the ability to modify the way that the last tab is closed.
Thanks! By the way, one other thing that's a little tweaky is that you can't create a Session called 'default'. It *appears* from my programmer's eye that the 'default' session that's used as a template for others is merely a regular session, named 'default' that is hidden from the user in the session list.

This may have been convenient to program, but it also 1) limits the user's choice of session names, and 2) produces inconsistent program behavior, since the default session is not in the list, yet it exists anyway and the user is warned they can't create one with that name. There's no real need to have implemented it this way - you could have made the default session visible but undeletable, or given it no name at all and kept separate from other sessions, so that users can name a session 'default' if they want to.

Just another suggestion to put in your list. :-)

- Tim
Reply With Quote
  #8  
Old 03-24-2010, 02:17 PM
rtb rtb is offline
VanDyke Technical Support
 
Join Date: Aug 2008
Posts: 4,306
Quote:
By the way, one other thing that's a little tweaky is that you can't create a Session called 'default'. It *appears* from my programmer's eye that the 'default' session that's used as a template for others is merely a regular session, named 'default' that is hidden from the user in the session list.
Hi Tim,

This isn't quite accurate. The default session is *not* a regular session. It is a template that is the foundation from which the Quick Connect dialog, and all ad hoc sessions derive their settings. It is accessible for editing from the General / Default Session category of the Global Options dialog. It is not listed in the Connect dialog because of the potential for cognitive friction. The Connect dialog is reserved for user defined sessions.
Quote:
1) limits the user's choice of session names
You are correct. Because the default session has been placed in the Session folder, there is one restriction placed on the name of a session in the root of the Sessions folder in the Connect dialog. You are welcome to use different variations of the word "default" in the root of the Sessions folder in the Connect dialog, or you can name a session "default" in a user created sub-folder in the Sessions folder of the Connect dialog.

It is interesting that you bring this up. This is the first time I can find since 1998 (when SecureCRT first started using the Default.ini file) that someone has requested that this behavior be changed.

Perhaps what you are saying is that this behavior is not adequately documented. If SecureCRT's help had better Default Session documentation including the restriction of having a user defined session named "default" in the Sessions folder of the Connect dialog, would this additional documentation have been helpful?
__________________
--Todd

VanDyke Software
Technical Support
support@vandyke.com
505-332-5730
Reply With Quote
  #9  
Old 03-25-2010, 01:58 AM
tbessie tbessie is offline
Registered User
 
Join Date: Mar 2010
Posts: 8
Quote:
Originally Posted by rtb
Hi Tim,

This isn't quite accurate. The default session is *not* a regular session. It is a template that is the foundation from which the Quick Connect dialog, and all ad hoc sessions derive their settings. It is accessible for editing from the General / Default Session category of the Global Options dialog. It is not listed in the Connect dialog because of the potential for cognitive friction. The Connect dialog is reserved for user defined sessions.

You are correct. Because the default session has been placed in the Session folder, there is one restriction placed on the name of a session in the root of the Sessions folder in the Connect dialog. You are welcome to use different variations of the word "default" in the root of the Sessions folder in the Connect dialog, or you can name a session "default" in a user created sub-folder in the Sessions folder of the Connect dialog.

It is interesting that you bring this up. This is the first time I can find since 1998 (when SecureCRT first started using the Default.ini file) that someone has requested that this behavior be changed.

Perhaps what you are saying is that this behavior is not adequately documented. If SecureCRT's help had better Default Session documentation including the restriction of having a user defined session named "default" in the Sessions folder of the Connect dialog, would this additional documentation have been helpful?
Maybe - I'll have to take a deeper look into what clues that there is such a session called 'default' exists (other than the Global properties "Default Session" button). If there's a list of sessions and one's called 'default', and the user can see it alongside the other sessions, that should be enough. If that's the case, my only confusion would be the lack of it showing in the Quick Connect dialog, but perhaps I am misinterpreting the function of the Quick Connect dialog; I had assumed it would contain all created Sessions.

Anyway, again, I'll look at it again to get a reality check. Thanks for the interest! :-)

- Tim
Reply With Quote
  #10  
Old 05-19-2011, 09:12 PM
smudge smudge is offline
Registered User
 
Join Date: Sep 2010
Posts: 16
Since it would be bad form to submit a duplicate feature request, does your request system have any kind of weighted system so that multiple requests for a feature get a higher priority? If so, please add another request for the original feature request of an "Except for last session" suboption to the "Close session on disconnect" option.

Thanks
Reply With Quote
  #11  
Old 05-20-2011, 08:01 AM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
Hello smudge,

Yes, the number of requests is one factor. I have added your post, and we can will post a follow up message if implemented. For direct e-mail notification, please let us know and refer to forum thread 5372.
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
  #12  
Old 05-25-2011, 03:53 PM
Olaf van der Spek Olaf van der Spek is offline
Registered User
 
Join Date: Jul 2004
Posts: 178
I don't use Close on Disconnect, but I'd like to be able to close the last tab manually.
Reply With Quote
  #13  
Old 05-25-2011, 04:11 PM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
Thanks Olaf,

I've recorded your request and we'll post a follow up message if we add the ability to close the last tab! Please let us know and refer to forum thread 5372 if you'd like to receive e-mail notification as well.
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
  #14  
Old 01-03-2012, 03:33 PM
Maureen's Avatar
Maureen Maureen is offline
VanDyke Product Director
 
Join Date: Feb 2004
Location: Albuquerque, NM
Posts: 1,531
The ability to close the last tabbed session, but leave the SecureCRT window open has been implemented in a pre-beta version of SecureCRT. If you would be interested in trying it, please send e-mail to me at Maureen.Jett@vandyke.com.

Maureen
Reply With Quote
  #15  
Old 04-06-2012, 03:04 AM
balmydrizzle balmydrizzle is offline
Registered User
 
Join Date: Apr 2012
Posts: 2
Smile my workaround

I just add a profile with ssh2 to 127.0.0.1 and goto options-global option-general-default session, click 'auto session' radio button, click add button to add this profile. In this way, It will leave a tab there, so the problem is avoid.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 06:31 PM.