bugGNU Screen - Bugs: bug #10074, sending a command to a screen...

 
 

bug #10074: sending a command to a screen started in daemon mode is silently ignored

Submitted by:  None
Submitted on:  Fri 20 Aug 2004 02:45:31 PM UTC  
 
Category: Program LogicSeverity: 3 - Normal
Priority: 4Status: Fixed
Privacy: PublicAssigned to: None
Open/Closed: ClosedRelease: 4.0.2
Fixed Release: 4.1.0Planned Release: Later
Work Required: 1 - Days

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon 25 May 2009 05:00:04 PM UTC, comment #7:

For those who cannot upgrade to the last release, here is a dirty workaround allowing to start processes in screens without having to attach manually before.

echo starting $basename screen
screen -d -m -S $basename
# we need to attach to the screen at least once before sending commands to it.
# So let's create an xterm in which we attach to the screen.
xterm -e "screen -r $basename" &
sleep 1
# detach the screen, this will wipe the xterm
screen -d $basename
# now we can send commands
screen -S $basename -X exec $basedir/$script

Anonymous
Sat 30 Aug 2008 09:32:30 PM UTC, comment #6:

Should be fixed by 3956383

Sadrul Habib Chowdhury <sadrul>
Project Administrator
Sat 12 Jul 2008 08:28:49 PM UTC, comment #5:

Is there anything wrong with making the last-created (or automatically created) window the "foreground", if none were preselected? At any rate, this strikes me as not really being crucial for a 4.1.0 release, then, so I'm retargetting (however, feel free to take this on anyway, if it strikes your fancy - I'll fold it in for 4.1.0 if someone completes it).

Micah Cowan <micahcowan>
Project Member
Sat 12 Jul 2008 03:49:44 PM UTC, comment #4:

This seems to happen because there's no foreground window when there has never been a display. So none of the commands that require foreground windows (e.g. clear, exec etc.) work. But other commands (e.g. screen, select etc.) do work.

Sadrul Habib Chowdhury <sadrul>
Project Administrator
Mon 23 Jun 2008 10:00:39 PM UTC, comment #3:

See also dupe: https://savannah.gnu.org/bugs/index.php?18882
Tracked on Debian BTS: http://bugs.debian.org/481411

Micah Cowan <micahcowan>
Project Member
Mon 23 Jun 2008 08:58:45 PM UTC, comment #2:

Tentatively targetting at 4.1.0; it may be that it will need to be punted for later, depending on what the source of the issue is.

Micah Cowan <micahcowan>
Project Member
 Spam posted by an anonymous
Sun 16 Jan 2005 07:59:40 PM UTC, comment #1:

I think I'm getting another side effect of the same bug...
I start a screen session, the get the associated STY (using screen -ls). In another terminal, the session being attached, after having export'ed correctly the STY environment variable, I can add windows containing what I want using screen command, which is the desired behavior. However, if the screen is detached, the very same command does not create a new window (it silently does nothing). If I reattach the screen anywhere and, from the STY-aware terminal, it type once again the same command, it works well.

(Not sure whether it's clear or not, this may help. In the following termN are plain xterm shells whereas screenN are shells open in the screen session called "test".)

term1$ screen -S test
screen1$ # so this is ok, one window open

term2$ screen -ls
There are screens on:
6796.test (Attached)
(...)
term2$ export STY=6796.test
term2$ screen bash
term2$ echo $?
0

# now I've got two windows in my screen (screen1 and screen2)

screen1$ ^Ad
[detached]
term1$ # OK

term2$ screen bash # this should open a third window
term2$ echo $?
0

term1$ screen -R test
screen1$ # still two windows instead of the three I was expecting

term2$ screen bash
term2$ echo $?
0

screen1$ # the window openned correctly (screen3)

Olivier Mehani <shtrom>
Fri 20 Aug 2004 02:45:31 PM UTC, original submission:

I downloaded, built and tested this with 'Screen version 4.00.02 (FAU) 5-Dec-03' on a PC running RedHat 8 with a custom 2.4.20 kernel.

Steps to reproduce:

screen -dmS test
screen -S test -X clear
screen -r test

(observe that the screen's screen has NOT been cleared)

detach from the screen with <ctrl>ad

screen -S test -X clear
screen -r test

(observe now that the screen's screen HAS been cleared)

It seems as though commands are ignored unless the screen has been attached at least once.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by sadrul (Posted a comment)
  • -unavailable- added by micahcowan (Updated the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 30 Aug 2008 09:32:30 PM UTCsadrulStatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.1.0
    Sat 12 Jul 2008 08:28:49 PM UTCmicahcowanPlanned Release4.1.0=>Later
    Tue 24 Jun 2008 12:05:49 AM UTCmicahcowanWork RequiredNone=>1 - Days
    Mon 23 Jun 2008 08:58:45 PM UTCmicahcowanCategoryNone=>Program Logic
      Priority5 - Normal=>4
      ReleaseNone=>4.0.2
      Planned ReleaseNone=>4.1.0
    Fri 13 Jun 2008 07:10:36 AM UTCmicahcowanStatusNone=>Confirmed
    Sun 16 Jan 2005 09:19:17 PM UTCshtromCarbon-Copy-=>Added shtrom

    Back to the top


    Powered by Savane 3.1-cleanup