Re: consistency probs var & function re-use

[Charles Daffern]

>First problem: If you are assigning a string to a variable,
> you need to put quotes around the string.  That shows that "-p"
> doesn't insert newlines:
> 
>  > x="$'foo\nbar'"
>  > declare -p x
>  declare -- x="\$'foo\\nbar'"

You do not have any newlines in that string, so of course the
demonstration with -p will show no newlines.

>> What are you trying to do? 
> Read var & func defs via a 'read' of 1 line.

In your variable "x" above, you have encoded the string in a format
which contains no raw newlines and which can be "eval"ed to produce the
original contents.
Why don't you encode the function the same way?




signature.asc
Description: OpenPGP digital signature

A background ssh can take over the tty from bash?

[Clark Wang]

(I'm using bash 4.4.12 on Debian 8)

Please follow the following steps to reproduce.

>From tty #1:

$ tty
/dev/pts/11
$ ssh -o ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0.0.1
root@127.0.0.1's password:
$ ps -C ssh uw
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root   716  0.0  0.2  44428   692 ?Ss   22:04   0:00 ssh -o
ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0
$
$ ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep
 &
[1] 725
$<-- Then I cannot input anything except CTRL-C

Go to tty #2:

$ ps t pts/11 jw
 PPID   PID  PGID   SID TTY  TPGID STAT   UID   TIME COMMAND
32714   725   725 32714 pts/11   32714 S0   0:00 ssh -o
ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep 
  579 32714 32714 32714 pts/11   32714 Ss+  0   0:00 bash
$

If I kill the "ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp
127.0.0.1 sleep " then tty #1 (pts/11) would be able to accept my input
again. Seems like the background "ssh" at tty #1 is consuming all input. I
cannot understand this since it should be stopped by SIGTTIN if it tries to
read from the tty.

Idea?

-clark

Re: A background ssh can take over the tty from bash?

[John McKown]

On Sat, Jun 10, 2017 at 9:19 AM, Clark Wang  wrote:

> (I'm using bash 4.4.12 on Debian 8)
>
> Please follow the following steps to reproduce.
>
> From tty #1:
>
> $ tty
> /dev/pts/11
> $ ssh -o ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0.0.1
> root@127.0.0.1's password:
> $ ps -C ssh uw
> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> root   716  0.0  0.2  44428   692 ?Ss   22:04   0:00 ssh -o
> ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0
> $
> $
> ​​
> ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep
>  &
> [1] 725
> $<-- Then I cannot input anything except CTRL-C
>
> Go to tty #2:
>
> $ ps t pts/11 jw
>  PPID   PID  PGID   SID TTY  TPGID STAT   UID   TIME COMMAND
> 32714   725   725 32714 pts/11   32714 S0   0:00 ssh -o
> ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep 
>   579 32714 32714 32714 pts/11   32714 Ss+  0   0:00 bash
> $
>
> If I kill the "ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp
> 127.0.0.1 sleep " then tty #1 (pts/11) would be able to accept my input
> again. Seems like the background "ssh" at tty #1 is consuming all input. I
> cannot understand this since it should be stopped by SIGTTIN if it tries to
> read from the tty.
>
> Idea?
>
> -clark
>

​IMO, not a bug in BASH, so this is the wrong forum. But, since I'm already
blathering on, I'd say the problem is that you have invoked "ssh"
incorrectly.​ In particular, ssh _does_ read from stdin normally. But, from
the man page:

 -f  Requests ssh to go to background just before command execution.
This is useful if ssh is going to ask for passwords
 or passphrases, but the user wants it in the background.  This
implies -n.  The recommended way to start X11 programs
 at a remote site is with something like ssh -f host xterm.

 If the ExitOnForwardFailure configuration option is set to
“yes”, then a client started with -f will wait for all
 remote port forwards to be successfully established before
placing itself in the background.


So instead of:

​
ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep 
&

Try:

​
ssh -f -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep


-- 
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

Buffer corruption when the terminal is resized.

[Paul Peet]

I would like to report a bug with bash (readline?). This bug can be
reproduced by opening gnome-terminal with bash running. By quickly
horizontally resizing the terminal window you can see that the buffer
seems to be corrupted as you see repeated or even removed lines or
characters.

At first I thought this might be an issue with gnome-terminal/vte but
this also happens with xterm so the conclusion was that it might be
bash/readline's fault.

This can be reproduced on stock Ubuntu 17.04.

Bash version: 4.4.7(1)-release (x86_64-pc-linux-gnu)
System: Linux 4.10.0-22-generic #24-Ubuntu SMP Mon May 22 17:43:20 UTC
2017 x86_64 x86_64

I've also uploaded a gif which shows this behavior:
https://media.giphy.com/media/3ohze1ynhK8ZDGmpq0/giphy.gif

Re: Buffer corruption when the terminal is resized.

[Eduardo Bustamante]

On Sat, Jun 10, 2017 at 04:56:35PM +0200, Paul Peet wrote:
> I would like to report a bug with bash (readline?). This bug can be
> reproduced by opening gnome-terminal with bash running. By quickly
> horizontally resizing the terminal window you can see that the buffer
> seems to be corrupted as you see repeated or even removed lines or
> characters.

What's the value of your PS1? (use: declare -p PS1)

-- 
Eduardo Bustamante
https://dualbus.me/

Re: Storing NUL in variables

[Pierre Gaston]

On Sat, Jun 10, 2017 at 2:06 AM, George  wrote:

> On Fri, 2017-06-09 at 20:58 +0300, Pierre Gaston wrote:
>
> On Fri, Jun 9, 2017 at 8:40 PM, Peter & Kelly Passchier 
>  wrote:
>
>
>
> On 09/06/2560 23:38, L A Walsh wrote:
>
>
> Chet Ramey wrote:
>
>
>
>  Should mapfile silently drop the NULs?
>
>
>
> Maybe add a flag to ignore NUL bytes that could be used in the 'read'
> statement as well?  If not specified, keep same behavior?
>
>
>
> That sounds like it might be useful.
> It might be more desirable to change it to a newline instead of dropping
> it? (Or both, with different flags??)
>
>
>
>
> I feel this kind of magic behavior would result in hackish scripts or fill
> a somewhat rare niche at best.
> I'd rather have bash to fully handle arrays of byte, or nothing.
>
>
>
> I think allowing shell variables to contain NUL would be lovely. How about
> we make that happen?  :)
> (I would be up for writing a patch to do it, of course, though I have a
> few other things in the pipeline... A feature like this could take a fair
> bit of work depending on how far the implementation goes in supporting
> various things.)
>
> Of course such variables couldn't be exported (the NULs would be lost if
> the data were stored in an environment variable) and for compatibility,
> variables should probably support containment of NULs only if the caller
> specifically requests it with an argument to "declare" or "read".
>
> ...And then there is the problem of how to use such variables. They can't
> be exported as environment variables or passed as command arguments, or
> used as file names...  Essentially they'd be limited to use in I/O within
> the shell, and within a handful of built-in commands or shell functions
> equipped to properly handle that data.
>
> I think that this approach, capturing an arbitrary byte stream and then
> taking further actions to process or encode it, is preferable to the
> alternative of capturing the byte stream and simultaneously encoding it
> into a text format. In principle commands like "read" shouldn't transform
> the data they're given, they should just store it. (I think the fact that
> read requires the option "-r" to read data without transforming it is kind
> of unfortunate...)
>
> (That said, one could argue that it would be equally reasonable, or even
> more reasonable to implement an operation that simultaneously reads and
> encodes the data, and another that decodes the data and writes it out, and
> then any commands designed to perform operations on byte stream data in the
> shell (re-encode it in a different format, etc.) should simply use that
> first encoding as a common format for exchanging the data..  Given the
> limitations of the shell with respect to its ability to handle NUL in
> various contexts, I think it's a reasonable argument. I tend to prefer the
> idea of providing true shell support for capturing a byte stream because it
> makes it easier to write code that handles the data without having to
> build-in a parser to interpret the data first.)
>
> One option that might make a feature like this integrate into the shell
> better would be to store a captured byte stream as an integer array rather
> than as an atomic variable. The back-end implementation in this case could
> be very efficient, and the stored data would be manipulable using existing
> array syntax. The main limitation perhaps would be that one could not
> create an array of these arrays.
>

Without too much thinking about it, I'd  propose something like this:

- extend readarray (or maybe provide another builtin)  to read bytes with
an interface like the one of dd (block size, offset, skip) and store the
bytes in the array. eg:  readarray -b bs=1024 cs=100 byte_array 

Re: Buffer corruption when the terminal is resized.

[George]

On Sat, 2017-06-10 at 11:20 -0500, Eduardo Bustamante wrote:
> On Sat, Jun 10, 2017 at 04:56:35PM +0200, Paul Peet wrote:
> > 
> > I would like to report a bug with bash (readline?). This bug can be
> > reproduced by opening gnome-terminal with bash running. By quickly
> > horizontally resizing the terminal window you can see that the buffer
> > seems to be corrupted as you see repeated or even removed lines or
> > characters.
> What's the value of your PS1? (use: declare -p PS1)
> 
It's actually shown in his video link...  Looks like at the start of PS1 he has 
\[ and \] surrounding escape characters rather than the whole escape
sequence:
\[\e\]0;
Rather than:
\[\e0;\]
Bash relies on \[ and \] to determine how much space is occupied by the prompt 
when it is to be redrawn, so in this case it thinks the prompt is 2
columns wider than it actually is.

Re: Buffer corruption when the terminal is resized.

[Paul Peet]

declare -- PS1="\\[\\e]0;\\u@\\h:
\\w\\a\\]\${debian_chroot:+(\$debian_chroot)}\\[\\033[01;32m\\]\\u@\\h\\[\\033[00m\\]:\\[\\033[01;34m\\]\\w\\[\\033[00m\\]\\\$
"


On Sat, Jun 10, 2017 at 6:47 PM, George  wrote:
> On Sat, 2017-06-10 at 11:20 -0500, Eduardo Bustamante wrote:
>
> On Sat, Jun 10, 2017 at 04:56:35PM +0200, Paul Peet wrote:
>
> I would like to report a bug with bash (readline?). This bug can be
> reproduced by opening gnome-terminal with bash running. By quickly
> horizontally resizing the terminal window you can see that the buffer
> seems to be corrupted as you see repeated or even removed lines or
> characters.
>
>
> What's the value of your PS1? (use: declare -p PS1)
>
> It's actually shown in his video link...  Looks like at the start of PS1 he
> has \[ and \] surrounding escape characters rather than the whole escape
> sequence:
>
> \[\e\]0;
>
> Rather than:
>
> \[\e0;\]
>
> Bash relies on \[ and \] to determine how much space is occupied by the
> prompt when it is to be redrawn, so in this case it thinks the prompt is 2
> columns wider than it actually is.

Re: Buffer corruption when the terminal is resized.

[Eduardo Bustamante]

On Sat, Jun 10, 2017 at 06:49:13PM +0200, Paul Peet wrote:
> declare -- PS1="\\[\\e]0;\\u@\\h:
> \\w\\a\\]\${debian_chroot:+(\$debian_chroot)}\\[\\033[01;32m\\]\\u@\\h\\[\\033[00m\\]:\\[\\033[01;34m\\]\\w\\[\\033[00m\\]\\\$
> "
[...]
> > Bash relies on \[ and \] to determine how much space is occupied by the
> > prompt when it is to be redrawn, so in this case it thinks the prompt is 2
> > columns wider than it actually is.

George already said it. There are two types of characters inside the
prompt string, visible and invisible. Color sequences are of the
invisible kind (these have an effect on the terminal, but do not occupy
any space on the line). You must wrap invisible character sequences with
\[ and \], otherwise Readline's calculation to figure out the physical
lenght of your prompt string will be off, and will cause the effect that
you're experiencing.

Try with:

#  v- this is an invisible sequence.
PS1='\[\e]0;\]\u@\h:\w\a\$...'
# ^  ^

instead.

-- 
Eduardo Bustamante
https://dualbus.me/

Re: Buffer corruption when the terminal is resized.

[Paul Peet]

If I understand this correctly this prompt (see below) shouldn't
contain any invisible sequence, therefore it doesn't require the
wrapping with \[ and \].

PS1="\u@\h\$"

So bash should be able to correctly calculate the prompt size and
such, but by resizing the window it still results in a corrupted
buffer.

I've uploaded another gif which shows this:
https://media.giphy.com/media/xUA7biW8UtwYIU6ggg/giphy.gif


On Sat, Jun 10, 2017 at 6:58 PM, Eduardo Bustamante  wrote:
> On Sat, Jun 10, 2017 at 06:49:13PM +0200, Paul Peet wrote:
>> declare -- PS1="\\[\\e]0;\\u@\\h:
>> \\w\\a\\]\${debian_chroot:+(\$debian_chroot)}\\[\\033[01;32m\\]\\u@\\h\\[\\033[00m\\]:\\[\\033[01;34m\\]\\w\\[\\033[00m\\]\\\$
>> "
> [...]
>> > Bash relies on \[ and \] to determine how much space is occupied by the
>> > prompt when it is to be redrawn, so in this case it thinks the prompt is 2
>> > columns wider than it actually is.
>
> George already said it. There are two types of characters inside the
> prompt string, visible and invisible. Color sequences are of the
> invisible kind (these have an effect on the terminal, but do not occupy
> any space on the line). You must wrap invisible character sequences with
> \[ and \], otherwise Readline's calculation to figure out the physical
> lenght of your prompt string will be off, and will cause the effect that
> you're experiencing.
>
> Try with:
>
> #  v- this is an invisible sequence.
> PS1='\[\e]0;\]\u@\h:\w\a\$...'
> # ^  ^
>
> instead.
>
> --
> Eduardo Bustamante
> https://dualbus.me/

Re: Buffer corruption when the terminal is resized.

[Eduardo Bustamante]

On Sat, Jun 10, 2017 at 07:21:36PM +0200, Paul Peet wrote:
> If I understand this correctly this prompt (see below) shouldn't
> contain any invisible sequence, therefore it doesn't require the
> wrapping with \[ and \].
> 
> PS1="\u@\h\$"
> 
> So bash should be able to correctly calculate the prompt size and
> such, but by resizing the window it still results in a corrupted
> buffer.
> 
> I've uploaded another gif which shows this:
> https://media.giphy.com/media/xUA7biW8UtwYIU6ggg/giphy.gif

I can't reproduce this with:


  dualbus@debian:~/src/gnu/bash$ bash --version | head -n1
  GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
  
  dualbus@debian:~/src/gnu/bash$ xterm -version
  XTerm(327)
  
  dualbus@debian:~/src/gnu/bash$ lsb_release -d
  Description:Debian GNU/Linux 9.0 (stretch)


Can you reproduce the problem using a more recent version. Perphaps try
the `devel' branch from git?  

-- 
Eduardo Bustamante
https://dualbus.me/

Re: Buffer corruption when the terminal is resized.

[Paul Peet]

Okay, I did the follwing:

> git clone https://git.savannah.gnu.org/git/bash.git
> cd bash && git checkout devel
> ./configure --prefix=/ --with-curses --enable-readline
> make

I then changed the default shell (in gnome-terminal) to the newly built bash.

> echo $BASH_VERSION
4.4.12(1)-maint

Unfortunately, I am still getting the same behavior as before (This
also happens with xterm for some reason.)

On Sat, Jun 10, 2017 at 11:20 PM, Eduardo Bustamante  wrote:
> On Sat, Jun 10, 2017 at 07:21:36PM +0200, Paul Peet wrote:
>> If I understand this correctly this prompt (see below) shouldn't
>> contain any invisible sequence, therefore it doesn't require the
>> wrapping with \[ and \].
>>
>> PS1="\u@\h\$"
>>
>> So bash should be able to correctly calculate the prompt size and
>> such, but by resizing the window it still results in a corrupted
>> buffer.
>>
>> I've uploaded another gif which shows this:
>> https://media.giphy.com/media/xUA7biW8UtwYIU6ggg/giphy.gif
>
> I can't reproduce this with:
>
>
>   dualbus@debian:~/src/gnu/bash$ bash --version | head -n1
>   GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
>
>   dualbus@debian:~/src/gnu/bash$ xterm -version
>   XTerm(327)
>
>   dualbus@debian:~/src/gnu/bash$ lsb_release -d
>   Description:Debian GNU/Linux 9.0 (stretch)
>
>
> Can you reproduce the problem using a more recent version. Perphaps try
> the `devel' branch from git?  
>
> --
> Eduardo Bustamante
> https://dualbus.me/

Re: A background ssh can take over the tty from bash?

[Clark Wang]

On Sat, Jun 10, 2017 at 11:00 PM, John McKown 
wrote:

> On Sat, Jun 10, 2017 at 9:19 AM, Clark Wang  wrote:
>
>> (I'm using bash 4.4.12 on Debian 8)
>>
>> Please follow the following steps to reproduce.
>>
>> From tty #1:
>>
>> $ tty
>> /dev/pts/11
>> $ ssh -o ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0.0.1
>> root@127.0.0.1's password:
>> $ ps -C ssh uw
>> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
>> root   716  0.0  0.2  44428   692 ?Ss   22:04   0:00 ssh -o
>> ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0
>> $
>> $
>> ​​
>> ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep
>>  &
>> [1] 725
>> $<-- Then I cannot input anything except CTRL-C
>>
>> Go to tty #2:
>>
>> $ ps t pts/11 jw
>>  PPID   PID  PGID   SID TTY  TPGID STAT   UID   TIME COMMAND
>> 32714   725   725 32714 pts/11   32714 S0   0:00 ssh -o
>> ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep 
>>   579 32714 32714 32714 pts/11   32714 Ss+  0   0:00 bash
>> $
>>
>> If I kill the "ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp
>> 127.0.0.1 sleep " then tty #1 (pts/11) would be able to accept my
>> input
>> again. Seems like the background "ssh" at tty #1 is consuming all input. I
>> cannot understand this since it should be stopped by SIGTTIN if it tries
>> to
>> read from the tty.
>>
>> Idea?
>>
>> -clark
>>
>
> ​IMO, not a bug in BASH, so this is the wrong forum. But, since I'm
> already blathering on, I'd say the problem is that you have invoked "ssh"
> incorrectly.​ In particular, ssh _does_ read from stdin normally. But, from
> the man page:
>
>  -f  Requests ssh to go to background just before command execution.
> This is useful if ssh is going to ask for passwords
>  or passphrases, but the user wants it in the background.
> This implies -n.  The recommended way to start X11 programs
>  at a remote site is with something like ssh -f host xterm.
>
>  If the ExitOnForwardFailure configuration option is set to
> “yes”, then a client started with -f will wait for all
>  remote port forwards to be successfully established before
> placing itself in the background.
>
>
> So instead of:
>
> ​
> ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep 
> &
>
> Try:
>
> ​
> ssh -f -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep
> 
>

Thanks but I want it to run as a background job in bash.

Re: Storing NUL in variables

[George]

On Sat, 2017-06-10 at 19:33 +0300, Pierre Gaston wrote:
> 
> 
> > > 
> > One option that might make a feature like this integrate into the shell 
> > better would be to store a captured byte stream as an integer array rather
> > than as an atomic variable. The back-end implementation in this case could 
> > be very efficient, and the stored data would be manipulable using
> > existing array syntax. The main limitation perhaps would be that one could 
> > not create an array of these arrays.
> > 
> Without too much thinking about it, I'd  propose something like this:
> 
> - extend readarray (or maybe provide another builtin)  to read bytes with an 
> interface like the one of dd (block size, offset, skip) and store the
> bytes in the array. eg:  readarray -b bs=1024 cs=100 byte_array 
> 
> - provide another builtin to write the array to a fd, eg "write bs=1024 
> cs=100 byte_array" (I don't really see a good way to extend printf or echo
> for this) 
> 
> -  setting an array directly would store the bytes eg a[0]=0 would put a null 
> bye at the first index
> 
> -  conversely ${a[0]} would expend to "0"
> 
> - I think the current array could even be use, but that would not be very 
> efficient, and there is the question of what to do with sparse arrays
> 
> - I think I would like some efficient way to copy range of bytes from one 
> array to the other, maybe this could be done reusing the above "write
> builtin" like: write offset=100 seek=50 -v dest_array -s source array 
> 
> 
> I think that could even been done with loadables builtins, making all the 
> byte arrays "special_variables"
> 
> My 2 centsof course I probably should have checked what zsh does as I 
> think it supports nullbytes in variable.
The talk of special variables brings me back to a previous feature request of 
mine: the ability to associate a data payload with a dynamic variable,
and a callback to allow the dynamic variable implementation to clean up that 
data when the variable is unset. (I am planning to write a patch to
provide this functionality - though I don't know if it will be accepted.)
The lack of that functionality stands in the way of implementing an efficient 
byte stream buffer as a dynamic variable using a "loadable builtin"
module. "Dynamic var" implementations have callbacks that may be used to get 
and set variable value, but nowhere to store state data associated with
the variable. This works fine for the dynamic vars that are defined by the 
shell, because each variable has its own implementation, and each
implementation is used for just one variable. There's a 1:1 relationship 
between dynamic variables and dynamic variable implementations, so dynamic
variable implementations can store their state data in global variables. 
Implementing something like a byte stream buffer as a dynamic would require
the ability to provide one backing implementation that could be used for 
multiple variables. As it stands, the only place you can store data in a
variable is in its "value" field - which must contain the textual 
representation of the variable's value.
(A compact byte-array type could be stored in a flat buffer, of course, so a 
dynamic var implementation would require the "dynamic variable data
pointer", but not the "dynamic variable unset callback" if it's assumed that 
unsetting a variable would also de-allocate the buffer indicated by the
data pointer: However in more general application of the "dynamic variable" 
functionality it would be useful to be able to use other data structures
to store the state of the variable: things like linked data structures. So for 
those applications an "unset callback" would be useful. An "unset
callback" would also allow things like using variable lifetimes to control 
other resources, like file descriptors, temporary files, or child
processes.)
I had initially thought the implementation of a byte-stream array could be 
similar to the existing implementation of an integer array. But (from what
I can tell) the implementation of an integer array is just the implementation 
of a string array, but with rules added to constrain the array elements
to numeric strings. (i.e. when assigning a value to such a variable, first 
evaluate the new value as a numeric expression to get an integer value for
the variable, then convert the numeric value to a string and store that. See 
make_variable_value() in variables.c, for instance.) So there would be no
value in creating a separate "byte array" type unless it either provided a 
significant performance advantage (by storing data internally as a byte
array, rather than a text-encoded byte array), or significantly more favorable 
semantics (for instance, expressing the bytes as hex rather than
decimal)
Unfortunately, that may torpedo the whole idea of implementing a type like this 
as a dynamic array var in Bash: even with a "dynamic var"
implementation of a byte array, compactly storing the byte stream in a buffer 
somewhere, as soon as anyone t