Re: read-only flag is lost for functions in sub shells
On Thu, Jul 31, 2014 at 04:45:20PM -0700, Linda Walsh wrote: Also noticing broken-ness upon using sudo -- functions defined at login are undefined: typeset -f|grep titlebar titlebar () declare -fx titlebar Some implementations of sudo clear the environment before elevating privileges. Clearing the environment would also remove exported functions, which are encoded as environment variables. You might be able to configure sudo to preserve your environment, but doing so is well beyond the scope of bug-bash.
Re: bug? type -P xxx returns xxx that isn't executable...(or readable)
On 8/1/14, 2:40 AM, Linda Walsh wrote: Chet Ramey wrote: type -P echo ls -l $(type -P echo) If you already have `echo' in the command hash table, type -P will return it, since that's what the shell will attempt to execute. --- It's not in the hash table, but type -P still returns the non-executable. OK, I see what's happening. In the absence of a hashed command, bash will return the first executable with the given name found in $PATH. If there are no executables with that name in $PATH, but bash finds a non-executable file by that name, bash will return (and attempt to execute) it. Bash has behaved this way for many years. In case you're wondering, shell behavior in this area varies widely. Bash, dash, zsh, and the 7th edition sh attempt to execute the non-executable file; ksh93, mksh, and the SVR4.2 sh report not found. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Tilde expansion during command search
On Friday, August 01, 2014 06:20:28 AM Mike Frysinger wrote: On Wed 23 Jul 2014 08:51:19 Dan Douglas wrote: On Wednesday, July 23, 2014 09:28:02 AM you wrote: On 7/23/14, 8:22 AM, Dan Douglas wrote: Hi, from this discussion: https://github.com/koalaman/shellcheck/issues/195#issuecomment-49678200 I can't find any reference that says substituting a literal tilde in PATH should occur during command search. Bash has always done this, even back to the pre-version 1 days, and I don't see any reason to change it now. The only concerns I can think of are inconsistency with programs that use execvp(), or possibly double-expansion in the event of a user name or any path containing ~. how so ? execvp doesn't do tilde expansion. only the shell does. That's the problem. A program using execvp should be able to expect the same result as that of the shell for a given PATH value. Because of this, it can't, unless exec has the same implementation. and it does it once at assignment. The example from my first post demonstrates that Bash substitutes a literal tilde in PATH during the actual path search before executing a command, in addition to during assignments and word expansions. -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: Tilde expansion during command search
On 08/01/2014 07:53 AM, Dan Douglas wrote: how so ? execvp doesn't do tilde expansion. only the shell does. That's the problem. A program using execvp should be able to expect the same result as that of the shell for a given PATH value. Because of this, it can't, unless exec has the same implementation. and it does it once at assignment. The example from my first post demonstrates that Bash substitutes a literal tilde in PATH during the actual path search before executing a command, in addition to during assignments and word expansions. And that bash is the odd one out in comparison to all other shells. I think bash is buggy for performing tilde expansion during PATH lookup for literal tildes contained in PATH, because no other shell does it, and POSIX does not specify that it would happen. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Tilde expansion during command search
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/1/14, 11:26 AM, Eric Blake wrote: On 08/01/2014 07:53 AM, Dan Douglas wrote: how so ? execvp doesn't do tilde expansion. only the shell does. That's the problem. A program using execvp should be able to expect the same result as that of the shell for a given PATH value. Because of this, it can't, unless exec has the same implementation. and it does it once at assignment. The example from my first post demonstrates that Bash substitutes a literal tilde in PATH during the actual path search before executing a command, in addition to during assignments and word expansions. And that bash is the odd one out in comparison to all other shells. I think bash is buggy for performing tilde expansion during PATH lookup for literal tildes contained in PATH, because no other shell does it, and POSIX does not specify that it would happen. Again: if it were a real problem, you'd think it would have come up more often in the past 25 years since it was implemented. - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPbsi0ACgkQu1hp8GTqdKtKGwCZAa+2Js8aibplmc17DPEBtEYd NQUAni/qbNXIQLiTQRfW052G9asC3lnY =oOKU -END PGP SIGNATURE-
Re: bug? type -P xxx returns xxx that isn't executable...(or readable)
Mike Frysinger wrote: type -P reflects what the shell will attempt, not what is useful. the fact that it's not usable is irrelevant. The fact that it is not usable is relevant. The type command says it will return the name of the file that will be executed if name was used as a command name, this is true. However, I would say that returning non-executable objects for use as a command is not very useful if you are looking for a command. If the file cannot be executed (and, especially, isn't readable), bash returns an answer it *knows* is wrong for use as a command. if you want to see if it's executable, use `[ -x ... ]`. -mike - Bash checks if they are executable -- when /bin/echo was executable, my PATH has /usr/bin before /bin and bash skipped /usr/bin/echo because it wasn't accessible and returned /bin/echo because it was executable. Only when /bin/echo was made unexecutable did bash return a non-executable file for use as a command -- instead of returning nothing (). It's also the case, that I can test if 'echo' is there or not, till I'm blue in the face, but that doesn't indicate whether or not the command will work, in this case, as it is a builtin. Maybe I'm in the minority, but I think the type command is *fundamentally*, used to look up commands -- things that are executable. Returning something that isn't because it fits some Faustian rules seems a bit perverse, no?
Re: bug? type -P xxx returns xxx that isn't executable...(or readable)
On Fri, Aug 01, 2014 at 12:30:58PM -0700, Linda Walsh wrote: Maybe I'm in the minority, but I think the type command is *fundamentally*, used to look up commands -- things that are executable. Returning something that isn't because it fits some Faustian rules seems a bit perverse, no? Well, in my experience it's more often used to *find out* whether a given thing is an external command, a function, an alias, a builtin, or a keyword. Its secondary purpose, in the specific case of external commands, is to display what the command's pathname is. But this is obviously subjective. My opinion, already expressed earlier in this thread, is that Bash is violating POSIX by yielding PATH lookup results that do not have the execute bit set. (I also found it quite surprising.) Since Bash actually conforms to POSIX when in POSIX mode, though, I assume that it does the other thing for historical reasons.
Bash-4.3 Official Patch 19
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-019
Bug-Reported-by:John Lenton
Bug-Reference-ID:
Bug-Reference-URL:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1317476
Bug-Description:
The -t timeout option to `read' does not work when the -e option is used.
Patch (apply with `patch -p0'):
*** ../bash-4.3-patched/lib/readline/input.c2014-01-10 15:07:08.0
-0500
--- lib/readline/input.c2014-05-22 18:40:59.0 -0400
***
*** 535,540
--- 538,551
else if (_rl_caught_signal == SIGHUP || _rl_caught_signal == SIGTERM)
return (RL_ISSTATE (RL_STATE_READCMD) ? READERR : EOF);
+ /* keyboard-generated signals of interest */
else if (_rl_caught_signal == SIGINT || _rl_caught_signal == SIGQUIT)
RL_CHECK_SIGNALS ();
+ /* non-keyboard-generated signals of interest */
+ else if (_rl_caught_signal == SIGALRM
+ #if defined (SIGVTALRM)
+ || _rl_caught_signal == SIGVTALRM
+ #endif
+ )
+ RL_CHECK_SIGNALS ();
if (rl_signal_event_hook)
*** ../bash-4.3-patched/builtins/read.def 2013-09-02 11:54:00.0
-0400
--- builtins/read.def 2014-05-08 11:43:35.0 -0400
***
*** 443,447
#if defined (READLINE)
if (edit)
! add_unwind_protect (reset_attempted_completion_function, (char *)NULL);
#endif
falarm (tmsec, tmusec);
--- 443,450
#if defined (READLINE)
if (edit)
! {
! add_unwind_protect (reset_attempted_completion_function, (char
*)NULL);
! add_unwind_protect (bashline_reset_event_hook, (char *)NULL);
! }
#endif
falarm (tmsec, tmusec);
***
*** 1022,1025
--- 1025,1029
old_attempted_completion_function = rl_attempted_completion_function;
rl_attempted_completion_function = (rl_completion_func_t *)NULL;
+ bashline_set_event_hook ();
if (itext)
{
***
*** 1033,1036
--- 1037,1041
rl_attempted_completion_function = old_attempted_completion_function;
old_attempted_completion_function = (rl_completion_func_t *)NULL;
+ bashline_reset_event_hook ();
if (ret == 0)
*** ../bash-4.3/patchlevel.h2012-12-29 10:47:57.0 -0500
--- patchlevel.h2014-03-20 20:01:28.0 -0400
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 18
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 19
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bash-4.3 Official Patch 21
BASH PATCH REPORT = Bash-Release: 4.3 Patch-ID: bash43-021 Bug-Reported-by:Jared Yanovich slovic...@gmail.com Bug-Reference-ID: 20140625225019.gj17...@nightderanger.psc.edu Bug-Reference-URL: http://lists.gnu.org/archive/html/bug-bash/2014-06/msg00070.html Bug-Description: When the readline `revert-all-at-newline' option is set, pressing newline when the current line is one retrieved from history results in a double free and a segmentation fault. Patch (apply with `patch -p0'): *** ../bash-4.3-patched/lib/readline/misc.c 2012-09-01 18:03:11.0 -0400 --- lib/readline/misc.c 2014-06-30 13:41:19.0 -0400 *** *** 462,465 --- 462,466 /* Set up rl_line_buffer and other variables from history entry */ rl_replace_from_history (entry, 0); /* entry-line is now current */ + entry-data = 0; /* entry-data is now current undo list */ /* Undo all changes to this history entry */ while (rl_undo_list) *** *** 469,473 FREE (entry-line); entry-line = savestring (rl_line_buffer); - entry-data = 0; } entry = previous_history (); --- 470,473 *** ../bash-4.3/patchlevel.h2012-12-29 10:47:57.0 -0500 --- patchlevel.h2014-03-20 20:01:28.0 -0400 *** *** 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 20 #endif /* _PATCHLEVEL_H_ */ --- 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 21 #endif /* _PATCHLEVEL_H_ */ -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bash-4.3 Official Patch 22
BASH PATCH REPORT = Bash-Release: 4.3 Patch-ID: bash43-022 Bug-Reported-by:scorp.dev.n...@gmail.com Bug-Reference-ID: E1WxXw8-0007iE-Bi@pcm14 Bug-Reference-URL: http://lists.gnu.org/archive/html/bug-bash/2014-06/msg00061.html Bug-Description: Using nested pipelines within loops with the `lastpipe' option set can result in a segmentation fault. Patch (apply with `patch -p0'): *** ../bash-4.3-patched/execute_cmd.c 2014-01-31 10:54:52.0 -0500 --- execute_cmd.c 2014-06-19 08:05:49.0 -0400 *** *** 2410,2414 lstdin = wait_for (lastpid); #if defined (JOB_CONTROL) ! exec_result = job_exit_status (lastpipe_jid); #endif unfreeze_jobs_list (); --- 2425,2438 lstdin = wait_for (lastpid); #if defined (JOB_CONTROL) ! /* If wait_for removes the job from the jobs table, use result of last !command as pipeline's exit status as usual. The jobs list can get !frozen and unfrozen at inconvenient times if there are multiple pipelines !running simultaneously. */ ! if (INVALID_JOB (lastpipe_jid) == 0) ! exec_result = job_exit_status (lastpipe_jid); ! else if (pipefail_opt) ! exec_result = exec_result | lstdin; /* XXX */ ! /* otherwise we use exec_result */ ! #endif unfreeze_jobs_list (); *** ../bash-4.3/patchlevel.h2012-12-29 10:47:57.0 -0500 --- patchlevel.h2014-03-20 20:01:28.0 -0400 *** *** 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 21 #endif /* _PATCHLEVEL_H_ */ --- 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 22 #endif /* _PATCHLEVEL_H_ */ -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug? type -P xxx returns xxx that isn't executable...(or readable)
Greg Wooledge wrote:
On Thu, Jul 31, 2014 at 11:40:18PM -0700, Linda Walsh wrote:
Ishtar:/ ll {,/usr}/bin/echo
-rw-r--r-- 2 136753 Nov 19 2013 /bin/echo
--w--- 2 136753 Nov 19 2013 /usr/bin/echo
sudo chmod +x /bin/echo
Ishtar:/ type -P echo
/bin/echo #correct
How is that correct? Neither of them is executable.
---
Did you miss the chmod right below the ll?
Bash behaves as expected in POSIX compatibility mode:
golem:~$ bash --posix -c 'command -v kumquat'
golem:~$ bash -c 'command -v kumquat'
/home/greg/bin/kumquat
In non-POSIX-compatibility mode, I guess you just have to iterate
through PATH yourself, or iterate through the results of type -a.
(Or toggle POSIX compatibility on just for this check.)
---
There are bugs in toggling on POSIX compatibility in that toggling
it on, then off, doesn't get you back to your starting state.
Example is remapping of the completion key. Go into posix, it remaps
it to some value (I assume you cannot remap completion keys in posix, else
there is no reason to reset the completion key at this point).
Then go back -- the TAB key is unmapped as a completion char,
but your old completion key is not remapped. So you end up with
no completion keys. There are probably lots of other one-way-adjustments,
but I haven't hit them all.
So the shell is less functional in non-posix mode in this case because
functionality isn't required? Um... and people wonder why we end up
with more requirements and regulation...
Re: read-only flag is lost for functions in sub shells
Greg Wooledge wrote: On Thu, Jul 31, 2014 at 04:45:20PM -0700, Linda Walsh wrote: Also noticing broken-ness upon using sudo: functions are undefined... Some implementations of sudo clear the environment before elevating privileges. Clearing the environment would also remove exported functions, which are encoded as environment variables. You might be able to configure sudo to preserve your environment, but doing so is well beyond the scope of bug-bash. --- The note in says there are two ways to deal with environment variables, reset w/whitelist or no-reset w/blacklist. Then it tells you: In all cases, environment variables with a value beginning with () are removed as they could be interpreted as bash functions. sudo is seriously broken in this regard, though I can't see where / when this change went in (i.e. quite possibly, been there, and my auto-scripted files reread in the definitions).
How to read fields into an array?
I tried setting a var as an array:
declare -a var
and then doing a read
read var
Is there a way to get arrays to work with read directly and
not doing something like a split on space into multiple lines and
use readarray w/that?
It seems like it would make sense if the declare -a var
actually had some effect on the subsequent read as
it does in subsequent assignments, for example.
Is there some syntax in the read to do it? (${a[@]} ?
Re: How to read fields into an array?
Linda Walsh wrote: I tried setting a var as an array: declare -a var and then doing a read read var never sorta mind ... read -a var is fine. (Though it would have been snazzy..)
Re: How to read fields into an array?
Remember to use help-bash for these questions.
