[Home]

Summary:ASTERISK-04702: CLI prompt always shown underneath cli command output
Reporter:Mark Hulber (hulber)Labels:
Date Opened:2005-07-27 09:04:34Date Closed:2011-06-07 14:10:49
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 4824.txt
( 1) asterisk.c.txt
Description:When I type

>zap show channel 3

for instance, the output is interleaved with CLI prompts.  When I type

>sip show peer x

then the output looks correctly embedded between two prompts.  I have had this problem for some time but I am currently using:

Asterisk CVS-HEAD built by root@asterisk.hulber.com on a i686 running Linux on 2005-07-23 04:46:40 UTC



****** ADDITIONAL INFORMATION ******

asterisk*CLI> show version
Asterisk CVS-HEAD built by root@asterisk.hulber.com on a i686 running Linux on 2005-07-23 04:46:40 UTC
asterisk*CLI> zap show channel 3
Channel: 3LI>
File Descriptor: 19
Span: 1
Extension:
Dialing: no
Context: verizon
Caller ID:
Calling TON: 0
Caller ID name:
Destroy: 0
InAlarm: 0
Signalling Type: FXS Kewlstart
Radio: 0
Owner: <None>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps, currently OFF
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Offhook
asterisk*CLI> sip show peer broadvoice-in
asterisk*CLI>

 * Name       : broadvoice-in
 Secret       : <Not set>
 MD5Secret    : <Not set>
 Context      : broadvoice-inbound
 Language     :
 AMA flags    : Unknown
 CallingPres  : Presentation Allowed, Not Screened
 Callgroup    :
 Pickupgroup  :
 Mailbox      :
 LastMsgsSent : -1
 Inc. limit   : 0
 Outg. limit  : 0
 Dynamic      : No
 Callerid     : "" <>
 Expire       : -1
 Expiry       : 900
 Insecure     : no
 Nat          : RFC3581
 ACL          : No
 CanReinvite  : No
 PromiscRedir : No
 User=Phone   : No
 DTMFmode     : rfc2833
 LastMsg      : 0
 ToHost       : sip.broadvoice.com
 Addr->IP     : 147.135.0.128 Port 5060
 Defaddr->IP  : 0.0.0.0 Port 0
 Def. Username:
 SIP Options  : (none)
 Codecs       : 0x8000e (gsm|ulaw|alaw|h263)
 Codec Order  : (none)
 Status       : OK (27 ms)
 Useragent    :
 Reg. Contact :

asterisk*CLI>
Comments:By: Mark Hulber (hulber) 2005-07-27 09:07:33

The example wasn't very severe.  Here's another example:

asterisk*CLI> zap show channel 3
Channel: 3LI>
File Descriptor: 19
Span: 1k*CLI>
Extension: I>
Dialing: noI>
Context: verizon
Caller ID: I>
Calling TON: 0
Caller ID name:
Destroy: 0LI>
InAlarm: 0LI>
Signalling Type: FXS Kewlstart
Radio: 0*CLI>
Owner: <None>
Real: <None>>
Callwait: <None>
Threeway: <None>
Confno: -1LI>
Propagated Conference: -1
Real in conference: 0
DSP: nok*CLI>
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps, currently OFF
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Offhook
asterisk*CLI>
By: Mark Hulber (hulber) 2005-07-27 11:09:48

Sorry, I don't have a disclaimer on file but this fixes it.  You are welcome to use this or a variant as you see fit since I took an example from existing Asterisk code.

[root@asterisk channels]# diff -u chan_zap.c chan_zap.c.new
--- chan_zap.c  2005-07-25 18:16:35.000000000 -0400
+++ chan_zap.c.new      2005-07-27 11:57:46.332373232 -0400
@@ -9309,7 +9309,7 @@
#endif
               channel = atoi(argv[3]);

-       ast_mutex_lock(lock);
+       ast_mutex_lock(&iflock);
       tmp = start;
       while (tmp) {
               if (tmp->channel == channel) {
@@ -9395,14 +9395,14 @@
                                       ast_cli(fd, "Hookstate (FXS only): %s\n", ps.rxisoffhook ? "Offhook" : "Onhook");
                               }
                       }
-                       ast_mutex_unlock(lock);
+                       ast_mutex_unlock(&iflock);
                       return RESULT_SUCCESS;
               }
               tmp = tmp->next;
       }

       ast_cli(fd, "Unable to find given channel %d\n", channel);
-       ast_mutex_unlock(lock);
+       ast_mutex_unlock(&iflock);
       return RESULT_FAILURE;
}


By: Clod Patry (junky) 2005-07-27 11:21:47

You should attach patches, like said in the bugs guidelines.
By: Mark Hulber (hulber) 2005-07-27 11:28:45

I don't have a disclaimer so I assume they aren't going to use the patch.  I did want to indicate how to fix it though.
By: Clod Patry (junky) 2005-08-19 16:22:17

any plan to disclaim that patch?
if not, we'll fix it.
By: Mark Hulber (hulber) 2005-08-19 17:31:23

This change is minor, it will be easier for you to fix it.  If at some point I start contributing substantially, I will work with my employer to get a disclaimer on file for myself.
By: Clod Patry (junky) 2005-08-19 22:41:54

That patch solves that problem.

Plus i placed the return after the #undef in zap_show_channels.

Disclaimer on file.


By: Kevin P. Fleming (kpfleming) 2005-08-22 22:33:37

What patch solves the problem? The patch in this bug only adds an additional newline to the output; is that the fix?
By: Michael Jerris (mikej) 2005-08-22 22:46:27

the attached 4824.txt according to junky (via irc)
By: Mark Hulber (hulber) 2005-08-22 22:46:27

Additional newline?  It locks the proper variable so that the CLI prompt doesn't interleave with the output of this function.
By: Clod Patry (junky) 2005-08-22 22:59:15

Apparently ast_cli is waiting a \n just after the fd.


without my patch:
debian*CLI> zap show channel 1
Channel: 1>
File Descriptor: 25
Span: 1
Extension:
Dialing: no
Context: default
Caller ID:
Calling TON: 0
Caller ID name: yes
Destroy: 0
InAlarm: 1
Signalling Type: FXS Kewlstart
Radio: 0
Owner: <None>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Relax DTMF: yes
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps, currently OFF
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Onhook
debian*CLI>



with my patch:
debian*CLI> zap show channel 1
debian*CLI>
Channel: 1
File Descriptor: 25
Span: 1
Extension:
Dialing: no
Context: default
Caller ID:
Calling TON: 0
Caller ID name: yes
Destroy: 0
InAlarm: 1
Signalling Type: FXS Kewlstart
Radio: 0
Owner: <None>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Relax DTMF: yes
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps, currently OFF
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Onhook
debian*CLI>



I've remark a lot of commands are like that too:
example:
debian*CLI> sip show channel 6735a662-37e2ef60-1cec17e1@192.168.123.10
debian*CLI>
 * SIP Call
 Direction:              Incoming
 Call-ID:                6735a662-37e2ef60-1cec17e1@192.168.123.10
[...]

and the code:
[...]
7544         while(cur) {
7545                 if (!strncasecmp(cur->callid, argv[3],len)) {
7546                         ast_cli(fd,"\n");
7547                         if (cur->subscribed)
[...]


When the first line if larger then the start of your asterisk prompt, you'll see the rest of your asterisk prompt if isn't a \n:
Example:
if you add this:
ast_cli(fd,"A1\n");
in handle_showuptime(cli.c) before the first ast_cli, you'll get:
debian*CLI> show uptime
A1bian*CLI>
System uptime: 5 seconds
debian*CLI>


instead of:
debian*CLI> show uptime
System uptime: 8 minutes, 3 seconds
debian*CLI>


Which proof it requires a \n before the first ast_cli, when that first text ast_cli is larger then the asterisk prompt.
By: Clod Patry (junky) 2005-08-22 23:21:50

Maybe hulber could tell if that works for him too?
By: Mark Hulber (hulber) 2005-08-23 06:15:28

I tried it.  It doesn't work all the time.  The problem is that a temporary variable is assigned to the mutex lock variable and then the mutex is done on the temp variable so the lock is ineffective.  You either need to use the global mutex variable or possibly dereference the temporary variable properly.  

I'm also not sure why you would want to see a prompt right after typing a command before seeing output.
By: Clod Patry (junky) 2005-08-23 07:04:08

hulber: I disagree on this, see my point related to the handle_showuptime?
Plus even with your patch, it doesnt fix that problem neither.
By: Mark Hulber (hulber) 2005-08-23 07:27:05

Don't know what to tell you.  Maybe you have found another problem.  It could be that there needs to be a mutex in show uptime or maybe there is some issue with ast_carefulwrite.

In any event, the mutex is in show channel for a reason and it's not working by referring to the temporary variable.
By: Mark Hulber (hulber) 2005-08-23 07:39:59

I do see one shortfall in the patch I listed above:

By referring back to &iflock the effect of the following statement is lost:

               if (pri) {
                       start = pri->crvs;
                       lock = &pri->lock;

so that logic will need to be fixed.  I think it might work to do something like this:

ast_mutex_lock **lock;

lock = &iflock;

ast_mutex_lock(*lock);

I'd have to play with it but I don't have time, sorry.
By: Kevin P. Fleming (kpfleming) 2005-08-23 11:14:42

There is no disclaimed patch here that solves the stated problem, and the poster has said they don't have time to produce a proper patch. This bug should be suspeneded until such time as a tested, disclaimed patch can be provided by someone.
By: Michael Jerris (mikej) 2005-08-23 11:16:58

hold off on suspending, junky is working on a fix.
By: Clod Patry (junky) 2005-08-23 19:33:27

There's a real problem somewhere else then:

areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI> show uptime
System uptime: 31 secondsreallyreallyreallyrealllonghost*CLI>
areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI>


and again, just a \n before the first output of ast_cli:
areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI> show uptime
areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI>
System uptime: 7 seconds


And i think the problem is much more then i though:
areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI> sip show peer 10
areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI>

 * Name       : 10reallyreallyreallyreallyrealllonghost*CLI>
 Secret       : <Set>llyreallyreallyreallyrealllonghost*CLI>
 MD5Secret    : <Not set>eallyreallyreallyrealllonghost*CLI>
 Context      : test_sipreallyreallyreallyrealllonghost*CLI>
 Language     : lyreallyreallyreallyreallyrealllonghost*CLI>
 AMA flags    : Unknownyreallyreallyreallyrealllonghost*CLI>
 CallingPres  : Presentation Allowed, Not Screenedghost*CLI>
 FromUser     : 10reallyreallyreallyreallyrealllonghost*CLI>
 Callgroup    : lyreallyreallyreallyreallyrealllonghost*CLI>
 Pickupgroup  : lyreallyreallyreallyreallyrealllonghost*CLI>
 Mailbox      : lyreallyreallyreallyreallyrealllonghost*CLI>
 LastMsgsSent : -1reallyreallyreallyreallyrealllonghost*CLI>
 Inc. limit   : 0yreallyreallyreallyreallyrealllonghost*CLI>
 Outg. limit  : 0yreallyreallyreallyreallyrealllonghost*CLI>
 Dynamic      : Yeseallyreallyreallyreallyrealllonghost*CLI>
 Callerid     : "" <>llyreallyreallyreallyrealllonghost*CLI>
 Expire       : 32reallyreallyreallyreallyrealllonghost*CLI>
 Expiry       : 900eallyreallyreallyreallyrealllonghost*CLI>
 Insecure     : noreallyreallyreallyreallyrealllonghost*CLI>
 Nat          : Alwayslyreallyreallyreallyrealllonghost*CLI>
 ACL          : Noreallyreallyreallyreallyrealllonghost*CLI>
 CanReinvite  : Noreallyreallyreallyreallyrealllonghost*CLI>
 PromiscRedir : Noreallyreallyreallyreallyrealllonghost*CLI>
 User=Phone   : Noreallyreallyreallyreallyrealllonghost*CLI>
 DTMFmode     : rfc2833yreallyreallyreallyrealllonghost*CLI>
 LastMsg      : 0yreallyreallyreallyreallyrealllonghost*CLI>
 ToHost       : lyreallyreallyreallyreallyrealllonghost*CLI>
 Addr->IP     : 192.168.123.10 Port 5060lyrealllonghost*CLI>
 Defaddr->IP  : 0.0.0.0 Port 5060llyreallyrealllonghost*CLI>
 Def. Username: 10reallyreallyreallyreallyrealllonghost*CLI>
 SIP Options  : (none)lyreallyreallyreallyrealllonghost*CLI>
 Codecs       : 0x6 (gsm|ulaw)reallyreallyrealllonghost*CLI>
 Codec Order  : (gsm|ulaw)allyreallyreallyrealllonghost*CLI>
 Status       : OK (82 ms)allyreallyreallyrealllonghost*CLI>
 Useragent    : PolycomSoundPointIP-SPIP_500-UA/1.3.1st*CLI>
 Reg. Contact : sip:10@192.168.123.10eallyrealllonghost*CLI>
areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI>
   -- Hungup 'IAX2/66.250.68.194:4569-1'lyrealllonghost*CLI>
 == Spawn extension (test_sip, 997, 3) exited non-zero on 'SIP/10-6346'
areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI>

areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI>


By: Mark Hulber (hulber) 2005-08-23 20:00:35

I don't think "show uptime" does a mutex.  sip_show_peer grabs a mutex but on a reference to some variable (s->lock) which might suffer the same aliasing problem as zap_show_channel.
By: Clod Patry (junky) 2005-08-23 20:13:11

That problem is everywhere:
areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI> show dialplan 2123@test_sip
There is no existence of 2123@test_sip extensionlonghost*CLI>
areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI>

areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI> show channels
Channel              Location             State   Application(Data)
0 active channelslyreallyreallyreallyreallyrealllonghost*CLI>
0 active callseallyreallyreallyreallyreallyrealllonghost*CLI>
areallyreallyreallyreallyreallyreallyreallyrealllonghost*CLI>
By: Clod Patry (junky) 2005-09-08 22:53:07

Any dev here? Can we go with the extra \n before any output?
i know isnt the perfect solution, but until now it works for all my ast_cli() output.
By: Corey Frang (gnarf) 2005-09-09 02:47:23

[patch] asterisk.c.txt - added a function called cli_unprompt that prints '\r' then empty space for each character long the prompt is, then '\r', instead of just printing '\r'

Should solve most of the problem, however there really should be a function in editline library that does this, someone should attack those folx.

My disclaimer is on file as well.
By: Corey Frang (gnarf) 2005-09-09 02:58:50

noticed one more problem.... if you type out a really long command, my cli_unprompt wont work if output gets printed:

   -- Executing Goto("IAX2/jasterisk@jasterisk-16384", "home|2298|1") in new stacksdfasdfasdfsdafdasfdsfsdf
   -- Goto (home,2298,1)fasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfsdafdasfdsfsdf
   -- Executing Answer("IAX2/jasterisk@jasterisk-16384", "") in new stackasdfasdfasdfasdfasdfsdafdasfdsfsdf
   -- Executing Wait("IAX2/jasterisk@jasterisk-16384", "1") in new stackfasdfasdfasdfasdfasdfsdafdasfdsfsdf
   -- Executing Authenticate("IAX2/jasterisk@jasterisk-16384", "4616") in new stackdfasdfasdfsdafdasfdsfsdf
   -- Playing 'agent-pass' (language 'en')
Sep  9 02:55:48 WARNING[32489]: file.c:564 ast_readaudio_callback: Failed to write framedfasdfsdafdasfdsfsdf
   -- Playing 'vm-goodbye' (language 'en')
 == Spawn extension (home, 2298, 3) exited non-zero on 'IAX2/jasterisk@jasterisk-16384'
   -- Hungup 'IAX2/jasterisk@jasterisk-16384'
asterisk*CLI> asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfsdafdasfdsfsdf


I'll look into in the morning, although I'm not sure that this one is easily solvable, nor extremely nessecary.  I know for a fact that without adding the support for this to editline, if the length of the command you are typing on the prompt, or for that matter your prompt extends past the last colum and wraps to the next line that there isn't anything that can be done to fix the printing of an extra line of CLI whenever the socket read gets stopped at a newline.
By: Mark Hulber (hulber) 2005-09-09 06:59:59

From looking at the code, it seems the intended methodology was to grab a lock to prevent any other output including the CLI prompt during the output of a command.  This locking is not being consistently done and it appears it isn't consistently working.

As I was tracing through things it appeared that ast_carefulwrite was a possible cause of CLI output showing up at the end of a line.
By: Corey Frang (gnarf) 2005-09-09 13:16:29

a) the ast_cli / ast_carefulwrite write to the unix socket, not the screen

static int ast_el_read_char(EditLine *el, char *cp)

That takes care of reading from the socket and printing the messages.

               if (fds[0].revents) {
                       res = read(ast_consock, buf, sizeof(buf) - 1);
                       /* if the remote side disappears exit */
                       if (res < 1) {
                             /***unimportant to this note***/
                       }

                       buf[res] = '\0';

                       if (!option_exec && !lastpos)
                               cli_unprompt();
                       write(STDOUT_FILENO, buf, res);
                       if ((buf[res-1] == '\n') || (buf[res-2] == '\n')) {
                               *cp = CC_REFRESH;
                               return(1);
                       } else {
                               lastpos = 1;
                       }

(that code has been modified by my patch, before my patch cli_unprompt was a line that printed \r)

The main chunk of code there basically says, if there is anything on the unix socket, read it, then if we are in CLI mode (!option_exec) and we last printed the command prompt (!lastpos) we clear out the prompt (previously it said to just print \r.  

Then we write the input from the socket to the screen, and if the buffer ends with a \n we redraw the prompt, otherwise we set lastpos and wait for more socket input.

I looked into the editline library, it will be hard to ever solve the two issues i talked about... But the patch I submitted will at least cleverly make the output of any command you just typed >seem< clean.

The only other way I can think to handle this that would stop most of the problems of extreme repeat would be to use another character to signify the end of a "command output" like perhaps a \n\t\r at the last line of the command output, this would be the signal to redraw the prompt, but before that, we ignore the prompt.  This would take a long time to do though I imagine since it would require updating everything...

The real solution to this problem requires editline to have a function that can clear the screen of the prompt + any user input, then move the cursor to the begining of that first prompt line.
By: Paul Cadach (pcadach) 2005-09-15 20:11:52

The problem is on asterisk.c:console_verboser() function:
   if (complete) {
       /* Wake up a poll()ing console */
       if (option_console && consolethread != AST_PTHREADT_NULL)
           pthread_kill(consolethread, SIGURG);
   }
If output line is complete (i.e. contains \r\n sequence) then by killing consolethread this function asks about output new prompt. Next output line written to console begins with \r (to move cursor to begin of the string) but the prompt still left on the screen, so it will be used as "background filler".

There is a solution: disable prompt refresh on catched SIGURG (or disable such kills()) before call to command execution function. When call is returned enable signal handling and send SIGURG to the console to refresh prompt.

But this will not help with "on-demand" messages such as errors, warnings, traces, etc. For such type of output cleaning out of prompt is required (by right filling lines shorter than prompt with spaces, for example).
By: Matt O'Gorman (mogorman) 2005-10-04 11:51:57

Hello

Any people attached to this bug know if the last suggested fix actually fixes the described problem.  Can we close this bug?

Matt
By: Michael Jerris (mikej) 2005-10-04 11:54:02

To my knowledge nothing has been commited to correct this issue so we should not close this bug.  I have myself not done any testing on the recomended fixes yet.
By: Corey Frang (gnarf) 2005-10-04 13:37:43

asterisk.c.txt is a decent band-aid for this problem, but it doesn't truely fix it.

I think the best way to fix it would be to add a clear_prompt() func to the editline library so that you can call it before generating any new output.  The only problem is that I couldn't figure out the multiple levels of "fake" screen buffers in that thing since i've never dealt with ncurses/termcap type programming before.

Also, I'm not aware if we could even modify that library, someone who knows the liscense game want to take a look at that?
By: Olle Johansson (oej) 2005-10-25 04:15:54

Has anyone tested with different terminal types in the UNIX/Linux shell? It might be some interoperability problem with the prompt and escape sequences sent.
By: Olle Johansson (oej) 2005-11-25 02:32:21.000-0600

No activity. Reopen when we have a solution.