tab and arrow keys
hi there while changing password with terminal/bash, it accepts tab and arrow keys along with characters,symbols and spacebar. But when we try to login into the system *"TAB and ARROW key" *perform their own usual task. So we can't enter the password and it tells that password is incorrect.i tried it with ubuntu and kali linux and i got the same problem. i reported this problem to ubuntu and kali linux. kali linux replied me that its not their problem. i am forwording that mail to you. thanks.
Fwd: [Kali Linux 0005256]: validation problem in password
-- Forwarded message - From: Kali Linux Bug Tracker Date: Mon, Feb 18, 2019 at 7:11 PM Subject: [Kali Linux 0005256]: validation problem in password To: The following issue has been CLOSED == https://bugs.kali.org/view.php?id=5256 == Reported By:azad1947 Assigned To:rhertzog == Project:Kali Linux Issue ID: 5256 Category: Kali Package Bug Reproducibility:always Severity: minor Priority: normal Status: closed Resolution: won't fix Fixed in Version: == Date Submitted: 2019-02-17 02:48 CET Last Modified: 2019-02-18 14:41 CET == Summary:validation problem in password Description: there is validation problem in password. if we change password with terminal ,it accepts arrow key and tab key and shows that password has been changed. But when we try to login and enter the same password , it does not accept arrow and tab key. Arrow and tab key perform their own usual task and system tells that password is incorrect and we can not log into the system. i think this problem is in every linux distribution. Recently i reported this problem to ubuntu. == -- (0010317) rhertzog (administrator) - 2019-02-18 14:41 https://bugs.kali.org/view.php?id=5256#c10317 -- This is not a problem that we want to look into in the context of Kali. As you said, it's not specific to Kali at all. You should check with the upstream development community of the program you used to change your password. Issue History Date ModifiedUsername FieldChange == 2019-02-17 02:48 azad1947 New Issue 2019-02-18 14:41 rhertzog Assigned To => rhertzog 2019-02-18 14:41 rhertzog Status new => closed 2019-02-18 14:41 rhertzog Resolution open => won't fix 2019-02-18 14:41 rhertzog Note Added: 0010317 ==
Re: tab and arrow keys
On 2/19/19 3:24 AM, azad vishwakarma wrote: > hi there > while changing password with terminal/bash, it accepts tab and arrow keys > along with characters,symbols and spacebar. But when we try to login into > the system *"TAB and ARROW key" *perform their own usual task. So we can't > enter the password and it tells that password is incorrect.i tried it with > ubuntu and kali linux and i got the same problem. What program are you using to change your password? It's probably not bash, and that program is where any change would need to be made. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: ${b+s ''}
On Sun, Feb 17, 2019 at 08:07:06PM -0500, Chet Ramey wrote:
> On 2/16/19 11:38 AM, sunnycemet...@gmail.com wrote:
> > I would like to include a null string as part of a parameter expansion word:
> >
> >> mapfile -t${bNullDelimited+d ''}
> >
> > When bNullDelimited is set, I expect this to expand to:
> >
> >> mapfile -td ''
> >
> > However, it expands to:
> >
> >> mapfile -td
>
> There are mixed behaviors. The idea behind the bash behavior is that a
> null string added to a non-empty word is simply discarded, and this happens
> while the word after the `+' is being processed, before word splitting.
>
> bash/ksh93/zsh do it one way, ash-derived shells/mksh/yash do it another.
Ugh. Shells are so messy.
wooledg:~$ ksh
$ args ${PATH+d ''}
1 args:
wooledg:~$ dash
$ args ${PATH+d ''}
2 args: <>
Looks like the best workaround (for bash/ksh) is to store the -d '' args
in an array, and use something like:
mapfile -t ${bNullDelimited+"${tmparray[@]}"}
This works in both ksh and bash; I did not test anything else (and of
course dash and other close-to-POSIX shells don't even *have* arrays, so
it's a good thing the workaround isn't needed there).
Then again, mapfile is bash-only, so you probably aren't looking for a
great level of portability here.
Re: tab and arrow keys
On Tue, Feb 19, 2019 at 09:24:38AM -0500, Chet Ramey wrote: > On 2/19/19 3:24 AM, azad vishwakarma wrote: > > hi there > > while changing password with terminal/bash, it accepts tab and arrow keys > > along with characters,symbols and spacebar. But when we try to login into > > the system *"TAB and ARROW key" *perform their own usual task. So we can't > > enter the password and it tells that password is incorrect.i tried it with > > ubuntu and kali linux and i got the same problem. > > What program are you using to change your password? It's probably not bash, > and that program is where any change would need to be made. To expand on this: there are many programs involved, and each one plays a separate role. First, you have your terminal (most likely a terminal emulator). This may be the Linux console, which is built into the Linux kernel, or it may be an xterm, konsole, gnome-terminal, rxvt-unicode, aterm, etc. That's one program. Then, you have bash, or some other shell, which runs inside a terminal and accepts commands that you type. When you type a command and press Enter, your shell tries to execute your command. The shell is the second program. Finally, you have whatever program you actually executed -- for example, "passwd" or "yppasswd" to change your system password from a shell in a terminal. When a shell executes a program like this, the program is communicating directly with your terminal. The shell steps completely out of the picture, and does not get involved until the other program finishes. How passwd handles something like the Tab or Enter key is entirely up to the passwd program. You could use the terminal layer to change the underlying meaning of a Tab key (for example, you could bind tab to the "intr" function, so it would act the way Ctrl-C normally does in this terminal), but that's about it. Now, this leads the other part of your question. Apparently your terminal-based program is faithfully letting you use tabs and arrow keys and so on in your passwords, but your graphical login is *not* letting you use those keys. So, the question is really: what result are you actually looking for? If you want your graphical login program (there are several different ones) to be able to handle a Tab character in a password, then you should file a bug report with the graphical login program. It's clearly not a problem in bash or in passwd or whatever you used that was successfully able to use the Tab character. Now, arrows are more complicated. The problem is that there isn't actually a "right arrow character", at least not in the same way that there is a universally understood "tab character". When you press an arrow key in a terminal emulator (in, say, X11), the terminal emulator receives two events from the windowing system: a "KeyPress event" and a "KeyRelease event", each with the associated "keysym" for this key (e.g. "keysym Right" for the right arrow key). When the terminal emulator receives the KeyRelease event, it looks up that keysym in its internal memory and maps it to a sequence of bytes which it sends to whatever application is receiving input from the terminal. This sequence is potentially different for each kind of terminal being emulated. For example, in xterm, the right arrow key maps to the sequence ESC [ C. In a Konsole or VT100 terminal, it's ESC O C. In a VT52 terminal, it's just ESC C. Suppose passwd is the program currently reading input from your terminal, and you press the right arrow key. If you're running it in an xterm, then you might be putting the characters ESC [ C into your password, assuming passwd is doing what we expect. Now suppose later you open a Konsole, and you try to change your password. You're asked to enter the current password first, but in this terminal, the right arrow key sends ESC O C instead of ESC [ C, so your password doesn't match. Do you consider this a bug? If so, in which program? In the terminal emulator? It's simply passing the bytes along. We live in a world where there are many different kinds of terminals, and they don't agree on the escape sequences for "special" keys. If your objective is to get every terminal to agree on those, you will fail. Sorry. In passwd, for not recognizing that this is a terminal escape sequence and yelling at you for trying to use it in a password? Do you expect passwd to recognize every possible escape sequence for every nonstandard key in every terminal emulator in the entire world? That seems like a tall order. I suppose you could argue that *any* password containing an ESC character should be rejected. You could try filing that bug with the maintainers of passwd. I'm curious to see what they would say. Personally, my advice to you would be: do not try to use Tabs or Arrow keys (or Home, Insert, Delete, Page Up, Page Down, Print Scrn, F1, F2, or any other "special" key) in a password. Stick to the regular ASCII character set. There are plenty of punctuation chara
Re: ${b+s ''}
On 2019-02-19 10:41, Greg Wooledge wrote:
On Sun, Feb 17, 2019 at 08:07:06PM -0500, Chet Ramey wrote:
On 2/16/19 11:38 AM, sunnycemet...@gmail.com wrote:
There are mixed behaviors. The idea behind the bash behavior is that a
null string added to a non-empty word is simply discarded, and this happens
while the word after the `+' is being processed, before word splitting.
bash/ksh93/zsh do it one way, ash-derived shells/mksh/yash do it another.
Ugh. Shells are so messy.
wooledg:~$ ksh
$ args ${PATH+d ''}
1 args:
wooledg:~$ dash
$ args ${PATH+d ''}
2 args: <>
Interesting. I will file this under fringe-case quirks. Thank you for
sharing other shells' behavior.
Re: nested bash 5 interactive sessions without job control
On 2/18/19 12:55 PM, Grisha Levit wrote: > On Sun, Feb 17, 2019 at 8:23 PM Chet Ramey wrote: >> Thanks for the report. I'll fix it in the next devel branch push. > > One more corner case, only shows up when bash is started by `login`: > > $ set +m; exec / > -bash: /: Is a directory > -bash: exec: /: cannot execute: Is a directory > $ echo "$(ps -o pid,tpgid -p $$)" > PID TPGID > 57430 57429 # 57429 is the login process > $ set -m; $(:) > -bash: child setpgid (57437 to 57430): Operation not permitted I can't reproduce this on my Mac OS X box when I run the devel version as a login shell and ssh to localhost. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: nested bash 5 interactive sessions without job control
On Tue, Feb 19, 2019, 7:28 PM Chet Ramey wrote: > I can't reproduce this on my Mac OS X box when I run the devel version > as a login shell and ssh to localhost. > I was also able to get the same result with $BASH -c "($BASH --norc -i -c 'set +m; exec /; set -m; \$(:)')" >
Re: nested bash 5 interactive sessions without job control
On 2/19/19 7:31 PM, Grisha Levit wrote: > -c "($BASH --norc -i -c 'set +m; exec /; set -m; \$(:)')" Thanks, I was able to reproduce it with this. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: ${b+s ''}
Date:Sun, 17 Feb 2019 20:07:06 -0500
From:Chet Ramey
Message-ID: <71d1418e-54a1-ddd4-6467-cbc27122e...@case.edu>
| The idea behind the bash behavior is that a
| null string added to a non-empty word is simply discarded,
This is clearly not POSIX compliant behaviour - POSIX requires that words
be accumulated as entered (seemingly redundant null strings or not)
and that quotes only get removed after field splitting has happened.
Of course, no-one cares how it is actually implemented, but the
effect has to be the same.
What's more, it is obvious that this doesn't happen consistently:
jinx$ x=abc
jinx$ xy=def
jinx$ echo $x''y
abcy
jinx$
(That's bash 5, but any other vers would do the same I think ... it is
also correct).
There the null string is being added to a non-empty word, but is
(correctly) not simply being discarded (or when it comes to time
to expand the var, xy would be expanded instead of x).
Similarly, bash does "$@"'' correctly. If there are no args ($# = 0)
then the "$@" vanishes, but the '' remains. Again, '' was appended
to a non-empty word, and is (correctly) not discarded - if it had been
then all that would be left would be "$@" which would produce nothing
at all, which would not be correct here.
[If $# != 0 the '' ends up being appended to the value of (what is
effectively) ${$#} (though that's not legal syntax, except maybe in zsh)
whereupon when quote removal happens, it vanishes.]
There are plenty more examples where null strings aren't simply disarded,
and I cannot think of any particularly good reason why the particular case
in question should be treated differently.
It is also clear that quotes in a situation like this aren't simply
being ignored in general:
jinx$ args ${PATH+a "b c"}
2:
which is also correct. Why are quotes around this one more important
than those in "" ?
It is actually wprse than it seems, as:
jinx$ x=
jinx$ args ${PATH+a "$x"}
1:
jinx$ x=b
jinx$ args ${PATH+a "$x"}
2:
jinx$ args ${PATH+a "$( : )"}
1:
It isn't just an explicit null string that is discarded, but
as that example shows, anything that ends up being null. This
is clearly a bug (whatever ksh93 does ... that has plenty of
other bugs). In the last of those it cannot really even be known
wether the result of the command substitution will be null or not
until it is evaluated (it could cotain a much more complicated
command than shown here, which only sometimes generates nothing).
Quoted null strings should never simply be discarded - not until
quote removal anyway when it is too late to make the word
containing it vanish, even if it contains nothing else.
kre
Re: ${b+s ''}
Date:Tue, 19 Feb 2019 10:41:41 -0500
From:Greg Wooledge
Message-ID: <20190219154141.di73jptd2ric6...@eeg.ccf.org>
| Looks like the best workaround (for bash/ksh) is to store the -d '' args
| in an array, and use something like:
|
| mapfile -t ${bNullDelimited+"${tmparray[@]}"}
No, the best workaround (which will work on all shells -- that the
command used here is bash specific is really irrelevant) was given in
the original message on this topic;
> mapfile -t${bNullDelimited+d} ${bNullDelimited+''}
That works, and works everywhere (except ksh93, which is simply
broken), but is needlessly cumbersome (and slower, as the var needs
to be looked up twice.)
kre
configure: gl_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER: command not found
Commit `be4078d25ff3af268a6ef7ab56c8121f9a8dfb36' introduced the following
issue:
| dualbus@system76-pc:~/src/gnu/bash$ ./configure --silent
|
| Beginning configuration for bash-5.0-maint for x86_64-pc-linux-gnu
|
| ./configure: line 9614: gl_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER: command not
found
| config.status: creating po/POTFILES
| config.status: creating po/Makefile
There's no mention of these changes in the changelog, so I don't really
understand what's broken or how to fix it.
I patched bash and ran `autoconf' to regenerate the `configure' file, and it
/seems/ to work, but I don't really know
what I'm doing:
diff --git a/MANIFEST b/MANIFEST
index cf957d3e..e30536f6 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -502,6 +502,7 @@ m4/nls.m4 f
m4/po.m4 f
m4/printf-posix.m4 f
m4/progtest.m4 f
+m4/pthread_rwlock_rdlock.m4f
m4/size_max.m4 f
m4/stdint_h.m4 f
m4/threadlib.m4f
diff --git a/configure.ac b/configure.ac
index ab8bc23f..81816ce8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -712,6 +712,7 @@ m4_include([m4/nls.m4])
m4_include([m4/po.m4])
m4_include([m4/printf-posix.m4])
m4_include([m4/progtest.m4])
+m4_include([m4/pthread_rwlock_rdlock.m4])
m4_include([m4/size_max.m4])
m4_include([m4/stdint_h.m4])
m4_include([m4/threadlib.m4])
diff --git a/m4/pthread_rwlock_rdlock.m4 b/m4/pthread_rwlock_rdlock.m4
new file mode 100644
index ..3c1d6456
--- /dev/null
+++ b/m4/pthread_rwlock_rdlock.m4
@@ -0,0 +1,165 @@
+# pthread_rwlock_rdlock.m4 serial 2
+dnl Copyright (C) 2017-2019 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+dnl From Bruno Haible.
+dnl Inspired by
+dnl
https://github.com/linux-test-project/ltp/blob/master/testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-2.c
+dnl by Intel Corporation.
+
+dnl Test whether in a situation where
+dnl - an rwlock is taken by a reader and has a writer waiting,
+dnl - an additional reader requests the lock,
+dnl - the waiting writer and the requesting reader threads have the same
+dnl priority,
+dnl the requesting reader thread gets blocked, so that at some point the
+dnl waiting writer can acquire the lock.
+dnl Without such a guarantee, when there a N readers and each of the readers
+dnl spends more than 1/Nth of the time with the lock held, there is a high
+dnl probability that the waiting writer will not get the lock in a given finite
+dnl time, a phenomenon called "writer starvation".
+dnl Without such a guarantee, applications have a hard time avoiding writer
+dnl starvation.
+dnl
+dnl POSIX:2017 makes this requirement only for implementations that support TPS
+dnl (Thread Priority Scheduling) and only for the scheduling policies
SCHED_FIFO
+dnl and SCHED_RR, see
+dnl
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rdlock.html
+dnl but this test verifies the guarantee regardless of TPS and regardless of
+dnl scheduling policy.
+dnl Glibc currently does not provide this guarantee, see
+dnl https://sourceware.org/bugzilla/show_bug.cgi?id=13701
+AC_DEFUN([gl_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER],
+[
+ AC_REQUIRE([gl_THREADLIB_EARLY])
+ AC_CACHE_CHECK([whether pthread_rwlock_rdlock prefers a writer to a reader],
+[gl_cv_pthread_rwlock_rdlock_prefer_writer],
+[save_LIBS="$LIBS"
+ LIBS="$LIBS $LIBMULTITHREAD"
+ AC_RUN_IFELSE(
+ [AC_LANG_SOURCE([[
+#include
+#include
+#include
+#include
+
+#define SUCCEED() exit (0)
+#define FAILURE() exit (1)
+#define UNEXPECTED(n) (exit (10 + (n)))
+
+/* The main thread creates the waiting writer and the requesting reader threads
+ in the default way; this guarantees that they have the same priority.
+ We can reuse the main thread as first reader thread. */
+
+static pthread_rwlock_t lock;
+static pthread_t reader1;
+static pthread_t writer;
+static pthread_t reader2;
+static pthread_t timer;
+/* Used to pass control from writer to reader2 and from reader2 to timer,
+ as in a relay race.
+ Passing control from one running thread to another running thread
+ is most likely faster than to create the second thread. */
+static pthread_mutex_t baton;
+
+static void *
+timer_func (void *ignored)
+{
+ /* Step 13 (can be before or after step 12):
+ The timer thread takes the baton, then waits a moment to make sure
+ it can tell whether the second reader thread is blocked at step 12. */
+ if (pthread_mutex_lock (&baton))
+UNEXPECTED (13);
+ usleep (10);
+ /* By the time we get here, it's clear that the second reader thread is
+ blocked at step 12. This is the desired behaviour. */
+ SUCCEED ();
+}
+
+static void *
+reader2_func (void *ignored)
+{
+ int err;
+
+ /* Step 8 (can be before or after step 7):
+ The second reader
