From amol.vinayak.deshpande at gmail.com  Fri Jan  1 18:03:38 2021
From: amol.vinayak.deshpande at gmail.com (Amol Deshpande)
Date: Fri, 1 Jan 2021 10:03:38 -0800
Subject: [Tcsh] unicode in prompt
In-Reply-To: <CAHiFnDnjifnAMHfPhikwDA+5Kdich1+hf2skT4_S6YQPe8KxYQ@mail.gmail.com>
References: <CAHiFnDnjifnAMHfPhikwDA+5Kdich1+hf2skT4_S6YQPe8KxYQ@mail.gmail.com>
Message-ID: <CAHiFnDm0Rh3GcmQN9P190A5KmKNQGmnDkQj9stc=7OYDZW1rnw@mail.gmail.com>

false alarm. turns out it was a user error. I was putting non-escape
characters in %{ %}.  I confused the details of LITERAL and QUOTE.
Everything's fine on Linux.

thanks,
-amol

On Mon, Dec 28, 2020 at 7:12 AM Amol Deshpande <
amol.vinayak.deshpande at gmail.com> wrote:

> hey all,
>
> I've been trying to get unicode in the prompt like all the cool kids are
> doing these days. I created a gist based on my attempts with the prompt
> configuration tool oh my posh (at
> https://github.com/JanDeDobbeleer/oh-my-posh3)
>
> my gist:
> https://gist.github.com/amoldeshpande/8b95c58b94fe2278b65ba10e44e5a27e
>
> However, even on Linux  (WSL2 in Windows), setting the prompt this way
> seems to mess up the editing.  backward-delete-word , line erase etc. don't
> quite work reliably. They erase more than required (visually. the actual
> command itself is intact in the shell's buffer)
>
> Anyone have experience with this ?
>
> For Linux, should I be setting my locale somehow  to enable unicode in the
> term ? I am assuming it should just work.
>
>  From stepping through on Windows it looks like the calculations for
> cursor location are messed up by UTF8.  But that's a whole different thing
> I'm struggling with, so I'm not sure it's related. Doesn't Unix use UTF-32
> anyway ?
>
> BTW, gmail has been ghosting this mailing list for me (I do seem to get
> replies to threads though), so please feel free to email me directly if
> anything needs my attention.  I'm in the process of setting up a different
> email.
>
> thanks and Happy Holidays to all
>
> regards,
> -amol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.astron.com/pipermail/tcsh/attachments/20210101/8a187754/attachment.htm>

From jamie at catflap.org  Sat Jan  2 00:26:12 2021
From: jamie at catflap.org (Jamie Landeg-Jones)
Date: Sat, 02 Jan 2021 00:26:12 +0000
Subject: [Tcsh] Further issues with jobcmd
In-Reply-To: <2ea031c0-d5db-49fd-ba00-f28d2441dbdf@www.fastmail.com>
References: <2ea031c0-d5db-49fd-ba00-f28d2441dbdf@www.fastmail.com>
Message-ID: <202101020026.1020QCUE024726@donotpassgo.dyslexicfish.net>

"Eduardo Alvarez" <ealvarez at fastmail.com> wrote:

> Hello, list,
>
> Last year, I reported an issues with jobcmd and ls (see "[Tcsh] ls prints 0m if xterm title is set via jobcmd" from September 18). I recently decided to revisit this configuration, using ls-F as a substitute, and in the process of testing I found another bit of odd behavior.
>
> Where it happens: I've seen this take place on Xterm and rxvt-unicode. No further tests have been conducted.
>
> How to reproduce:
>
> 1. Alias jobcmd as follows. Again, note the un-escaped semicolon, which is necessary for this to work correctly:
>
>     alias jobcmd 'echo -n "\033]2;\!#:q\007"'
>
> 2. Run any command that uses an argument. I used "man man",  "vim foo", and "ls /etc" as tests.
> 3. If it's a full-screen program (such as vim or man), close the app.
> 4. Press up arrow or CTRL-P to invoke up-history.

>
> What should happen:
>
> The history mechanism should put the last command executed, complete with its arguments (eg, man man).
>
> What happens:
>
> The history mechanism prints only the command, without arguments. If up-history is invoked again, however, then the command + argument is displayed.
>
> Oddly enough, executing "history" only shows the command and its arguments, there isn't a listing in history with just the command.
>
> Thanks in advance for the help,

In my tcshrc, I have a piece of code in "postcmd" that sets a variable "this_command". I hit the
same problem a while back. My tcshrc currently contains:

## _____________________________________________________________________________________________________
## NB: In the following command, instead of the snippet:   set this_command="`history -h 1`";
##     , we should have been able to use:                  set this_command='"'"'\!#:0:q \!#:*:q'"'"';
##
##     However, this produces a bug that messes up the interactive session history
##     (in particular, using up-arrow to move backwards in history)
## _____________________________________________________________________________________________________
##

I don't have a fix, but does the workaround I used above work for you?

Cheers
   Jamie

From naddy at mips.inka.de  Sat Jan 30 23:35:17 2021
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Sun, 31 Jan 2021 00:35:17 +0100
Subject: [Tcsh] 6.22.03: testsuite failures due to unbalanced parentheses
Message-ID: <YBXtNfWMdlEdLBI+@lorvorc.mips.inka.de>

Running the testsuite for tcsh 6.22.03 on OpenBSD shows three failures:
139 182 196

The errors are all alike:

------------------->
139: Filename substitution                          ./tests/testsuite: /usr/obj/
tcsh-6.22.03/tcsh-6.22.03/testsuite.dir/at-groups/139/test-source[79]: syntax er
ror: `}' unexpected
testsuite: WARNING: unable to parse test group: 139
testsuite: WARNING: A failure happened in a test group before any test could be
testsuite: WARNING: run. This means that test suite is improperly designed.  Please
testsuite: WARNING: report this failure to <https://bugs.astron.com/>.
 FAILED (subst.at:29)
<-------------------

A closer look at the testsuite script reveals that autom4te generates
invalid shell code:

------------------->
( $at_check_trace; ((
case "$(uname -s)" in
Darwin)
    HOME=$(dscl . read "/Users/$USER" NFSHomeDirectory | awk '{ print $NF }')
    ;;
*)
    HOME=$(getent passwd $(id -un) | awk -F: '{ print $(NF - 1) }')
    ;;
esac;
export HOME;
echo 'echo ~; echo "$HOME"' | tcsh -f | uniq | wc -l | tr -d ' \t'

) >>"$at_stdout" 2>>"$at_stderr" 5>&-
<-------------------

Notice the trailing "((" in the first line.  Whether you treat is
as opening a ksh-style arithmetic expression or two sub-shells, it
is unmatched and simply wrong.

I have been unable to find details, but apparently some processing
step in autom4te inserts the corresponding number of opening
parentheses to match the closing ones that are part of the case
statement.  This seems related:
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Balancing-Parentheses.html

I'm uncertain what the correct solution is, but []-quoting the
parentheses in the case statements fixes the problem:

--- tests/subst.at.orig
+++ tests/subst.at
@@ -52,10 +52,10 @@ foo* ab{c,d} ^fo*
 
 AT_CHECK([
 case "$(uname -s)" in
-Darwin)
+Darwin[)]
     HOME=$(dscl . read "/Users/$USER" NFSHomeDirectory | awk '{ print $NF }')
     ;;
-*)
+*[)]
     HOME=$(getent passwd $(id -un) | awk -F: '{ print $(NF - 1) }')
     ;;
 esac;
@@ -67,10 +67,10 @@ echo 'echo ~; echo "$HOME"' | tcsh -f | uniq | wc -l |
 
 AT_CHECK([
 case "$(uname -s)" in
-Darwin)
+Darwin[)]
     HOME=$(dscl . read "/Users/$USER" NFSHomeDirectory | awk '{ print $NF }')
     ;;
-*)
+*[)]
     HOME=$(getent passwd $(id -un) | awk -F: '{ print $(NF - 1) }')
     ;;
 esac;
--- tests/variables.at.orig
+++ tests/variables.at
@@ -593,10 +593,10 @@ echo $home
 ]])
 AT_CHECK([
 case "$(uname -s)" in
-Darwin)
+Darwin[)]
     HOME=$(dscl . read "/Users/$USER" NFSHomeDirectory | awk '{ print $NF }')
     ;;
-*)
+*[)]
     HOME=$(getent passwd $(id -un) | awk -F: '{ print $(NF - 1) }')
     ;;
 esac;
@@ -721,10 +721,10 @@ AT_CLEANUP
 AT_SETUP([$ cdtohome])
 AT_CHECK([
 case "$(uname -s)" in
-Darwin)
+Darwin[)]
     HOME=$(dscl . read "/Users/$USER" NFSHomeDirectory | awk '{ print $NF }')
     ;;
-*)
+*[)]
     HOME=$(getent passwd $(id -un) | awk -F: '{ print $(NF - 1) }')
     ;;
 esac;

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de