Re: Looking for tutorials
On Fri, Mar 18, 2016 at 02:36:46PM -0400, ty armour wrote: > I am looking for tutorials on every and any aspect of developing bash. I > would be looking to write my own bash commands in assembly and C Oh, good, then you can help fix and polish the loadable builtin framework. It's been in bash for a long time, but the upcoming 4.4 is the first version where it's really intended as a feature for ordinary installations. It needs a lot more work, in my opinion. You can start by figuring out how to make it work and writing up a document for that part. After that, you can figure out what internal bash functions are available for use in user-written builtins, and write an API document for that.
Re: bash 4.4-rc1 EXECIGNORE not fully working?
Eric Blake writes: > But I don't know whether bash is calling exec[lv] with a canonicalized > name instead of exec[lv]p() with the kernel doing the lookup; PATH searching is a pure user-space concept. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: mv to a non-existent path now renames instead of failing
2016-03-17 09:00:37 -0600, Eric Blake: [...] > That said, if you WANT an error if 'two/' does not exist, and to move > 'one' to 'two/one' if 'two/' does exist, you can always use: > > mv one two/. > > where the trailing '.' changes the semantics required of the rename() > call, and forces an error if 'two/' does not exist. [...] See also the GNU-specific mv -t two one To move one into two. For the reverse: force a move-to as opposed to a move-into, another GNU-specific option: mv -T one two if two is a directory, you'll get an error. If two is a symlink (to directory or other), one is renamed to two (and the symlink is gone). FreeBSD mv has: mv -h one two To do a move-to instead of move-into when "two" is a symlink to a directory. -- Stephane
Re: mv to a non-existent path now renames instead of failing
On 03/17/2016 05:37 AM, a...@korath.teln.shikadi.net wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
> -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_FORTIFY_SOURCE=2
> -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
> -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
> -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
> -DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
> uname output: Linux korath.teln.shikadi.net 4.5.0-1-drm-intel-nightly #1 SMP
> PREEMPT Sun Mar 13 10:42:04 AEST 2016 x86_64 GNU/Linux
> Machine Type: x86_64-unknown-linux-gnu
>
> Bash Version: 4.3
> Patch Level: 42
> Release Status: release
>
> Description:
> Moving a directory to a non-existent path will rename the directory
> instead
> of reporting that the destination directory does not exist.
This has nothing to do with bash, and would belong better on the
bug-coreutils mailing list, if it were a bug. However,...
>
> Repeat-By:
> rmdir two 2> /dev/null
> mkdir one
> mv one two/
POSIX requires this to succeed, and renames 'one/' to 'two/'.
>
> This should (and did in earlier versions) return an error, since the
> "two"
> directory does not exist, so the "one" folder cannot be moved inside of
> it.
You are NOT moving 'one' to 'two/one', but renaming 'one' to 'two'.
That is what POSIX requires, so no error is needed.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
"This first synopsis form is assumed when the final operand does not
name an existing directory and is not a symbolic link referring to an
existing directory."
That sums up your situation ('two/' does not exist, so you are doing 'mv
source target_file', not 'mv source target_dir'), at which point steps 1
and 2 do not apply, and step 3 states you are doing
rename("one","two/"), which succeeds because "one" is a directory (if
"one" were not a directory, it would fail).
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: bash 4.4-rc1 EXECIGNORE not fully working?
On 03/18/2016 10:35 AM, Greg Wooledge wrote:
> On Fri, Mar 18, 2016 at 10:27:54AM -0600, Eric Blake wrote:
>> What were you expecting to have happen? EXECIGNORE only controls
>> whether a file matching the glob is excluded from tab completions (which
>> it sounds like it did), not whether bash will avoid executing it (and
>> you proved that it is still executable).
>
> The man page says,
>
>EXECIGNORE
> A colon-separated list of shell patterns (see Pattern Matching)
> defining the list of filenames to be ignored by command search.
> Files whose full pathnames match one of these patterns are not
> considered executable files for the purposes of completion and
> command execution.
>
> I believe this agrees more with Dennis's interpretation.
Then we have a documentation bug in my feature submission; Chet changed
the wording I proposed, which was:
https://lists.gnu.org/archive/html/bug-bash/2015-04/msg00130.html
address@hidden EXECIGNORE
+A colon-separated list of extended glob patterns (@pxref{Pattern
+Matching}). Files with full paths matching one of these patterns are
+not considered executable for the purposes of completion and PATH
+searching, but the @code{[}, @code{[[}, and @code{test} builtins are
+not affected. Use this variable to ignore shared library files that
+must have the executable bit set, but which are not actually
+executable.
We've demonstrated that it affects PATH searching insofar that 'type -a'
no longer lists the program, but it does NOT change any exec[lv]p() PATH
searching (if the kernel searches for 'ls', it will find it no matter
what bash has in EXECIGNORE). But I don't know whether bash is calling
exec[lv] with a canonicalized name instead of exec[lv]p() with the
kernel doing the lookup; nor do I have any strong opinions about whether
EXECIGNORE should be able to completely blacklist the execution of a
particular program, so much as only hiding it from tab-completion.
Maybe the compromise is calling this report a doc bug, and changing
Chet's wording to nuke the trailing "and command execution", so that it
remains as documented mention that it affects ONLY completion (since
'type -a' is similar to completion in nature).
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: bash 4.4-rc1 EXECIGNORE not fully working?
On 03/18/2016 11:36 AM, Andreas Schwab wrote: > Eric Blake writes: > >> But I don't know whether bash is calling exec[lv] with a canonicalized >> name instead of exec[lv]p() with the kernel doing the lookup; > > PATH searching is a pure user-space concept. Fine. Then read that as "with libc doing the lookup", since execlvp() is just a libc wrapper around the kernel execve(). The point I was trying to get at was that I don't know if bash does all the PATH lookups itself, or if it delegates; and therefore, I don't know if EXECIGNORE can (or should) affect PATH lookups. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: mv to a non-existent path now renames instead of failing
On Thu, Mar 17, 2016 at 1:37 PM, wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' > -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_FORTIFY_SOURCE=2 > -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong > -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' > -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' > -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' > uname output: Linux korath.teln.shikadi.net 4.5.0-1-drm-intel-nightly #1 > SMP PREEMPT Sun Mar 13 10:42:04 AEST 2016 x86_64 GNU/Linux > Machine Type: x86_64-unknown-linux-gnu > > Bash Version: 4.3 > Patch Level: 42 > Release Status: release > > Description: > Moving a directory to a non-existent path will rename the > directory instead > of reporting that the destination directory does not exist. > > Repeat-By: > rmdir two 2> /dev/null > mkdir one > mv one two/ > > This should (and did in earlier versions) return an error, since > the "two" > directory does not exist, so the "one" folder cannot be moved > inside of it. > If the trailing slash was left off "two/", the command should (and > does, > and always did) rename the folder. However recently the command > with the > trailing slash has started renaming the folder instead of > returning an > error. > > I often rely on the error result so that I don't have to check > whether the > destination directory exists before performing the move operation, > but now > the process will always succeed, silently becoming a rename > operation > unpredictably. I have already lost a handful of folders this way, > only > realising later that they were renamed without warning when I did > not > intend them to be renamed. > > > Thanks for the report, however bash is not involved, it is just passing the argument to the "mv" command. I can reproduce the behaviour with gnu mv, so maybe you are also using this version, in which case you should report to https://lists.gnu.org/mailman/listinfo/bug-coreutils (I can reproduce with mv version 5.97 from 2006 so it's probably not that new)
Re: mv to a non-existent path now renames instead of failing
On Thu, Mar 17, 2016 at 09:37:57PM +1000, a...@korath.teln.shikadi.net wrote: > Repeat-By: > rmdir two 2> /dev/null > mkdir one > mv one two/ > > This should (and did in earlier versions) return an error This report needs to be sent to the GNU coreutils mailing list, rather than the bash mailing list. mv is part of coreutils, not a bash shell builtin. Be sure to include the output of "mv --version" (or at least the first line) in your report.
Re: mv to a non-existent path now renames instead of failing
On 03/17/2016 08:49 AM, Eric Blake wrote: >> Repeat-By: >> rmdir two 2> /dev/null >> mkdir one >> mv one two/ > > POSIX requires this to succeed, and renames 'one/' to 'two/'. That said, if you WANT an error if 'two/' does not exist, and to move 'one' to 'two/one' if 'two/' does exist, you can always use: mv one two/. where the trailing '.' changes the semantics required of the rename() call, and forces an error if 'two/' does not exist. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: bash 4.4-rc1 EXECIGNORE not fully working?
On 03/18/2016 10:09 AM, Dennis Williamson wrote: > $ type -a ls > ls is /bin/ls > $ # ls tab completion includes ls > $ ls foo > foo > $ EXECIGNORE=/bin/ls > $ type -a ls > bash: type: ls: not found > $ # ls tab completion does not include ls > $ ls foo > foo > $ /bin/ls foo > foo > > So ls is still executed despite the setting. I tried the same with > /usr/bin/find and got the same result. What were you expecting to have happen? EXECIGNORE only controls whether a file matching the glob is excluded from tab completions (which it sounds like it did), not whether bash will avoid executing it (and you proved that it is still executable). The main use for EXECIGNORE is for ignoring *.so or *.dll files, which must have executable permissions, but which you do not want polluting tab completion. So, without further details, I don't see any bug here. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: bash 4.4-rc1 EXECIGNORE not fully working?
On 3/18/16 12:09 PM, Dennis Williamson wrote: > $ type -a ls > ls is /bin/ls > $ # ls tab completion includes ls > $ ls foo > foo > $ EXECIGNORE=/bin/ls > $ type -a ls > bash: type: ls: not found > $ # ls tab completion does not include ls > $ ls foo > foo > $ /bin/ls foo > foo > > So ls is still executed despite the setting. I tried the same with > /usr/bin/find and got the same result. Yes, this is my fault. I did not check the original patch carefully enough. It claimed to inhibit executables found via a PATH search, but did not do a complete job. (I also managed to drop the last line from the original patch.) It's an easy one-line fix to make the behavior match the documentation, at least with respect to PATH searching, and that will be in the bash-4.4 release. You should note that it would never have worked given the example above; the first time you executed ls -- before setting EXECIGNORE -- put the full pathname into the hash table and inhibited future path lookups. I need to modify the documentation to clarify that it only affects PATH lookups. 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: bash 4.4-rc1 EXECIGNORE not fully working?
On 3/18/16 1:05 PM, Eric Blake wrote: > Maybe the compromise is calling this report a doc bug, and changing > Chet's wording to nuke the trailing "and command execution", so that it > remains as documented mention that it affects ONLY completion (since > 'type -a' is similar to completion in nature). I think the better fix, and something that makes the name more appropriate, is to fix the code so that it affects all PATH searching and change the documentation to say that it affects PATH searching for command execution. -- ``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/ signature.asc Description: OpenPGP digital signature
mv to a non-existent path now renames instead of failing
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' uname output: Linux korath.teln.shikadi.net 4.5.0-1-drm-intel-nightly #1 SMP PREEMPT Sun Mar 13 10:42:04 AEST 2016 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.3 Patch Level: 42 Release Status: release Description: Moving a directory to a non-existent path will rename the directory instead of reporting that the destination directory does not exist. Repeat-By: rmdir two 2> /dev/null mkdir one mv one two/ This should (and did in earlier versions) return an error, since the "two" directory does not exist, so the "one" folder cannot be moved inside of it. If the trailing slash was left off "two/", the command should (and does, and always did) rename the folder. However recently the command with the trailing slash has started renaming the folder instead of returning an error. I often rely on the error result so that I don't have to check whether the destination directory exists before performing the move operation, but now the process will always succeed, silently becoming a rename operation unpredictably. I have already lost a handful of folders this way, only realising later that they were renamed without warning when I did not intend them to be renamed.
Looking for tutorials
I am looking for tutorials on every and any aspect of developing bash. I would be looking to write my own bash commands in assembly and C and would be looking to implement versions of bash in both windows and Mac OS x. It can be done, but it takes a bit of time and thinking to get it done. I would also be looking to develop audio and graphics frameworks and stuff like that that would work under bash, and ssh frameworks and networking frameworks too. Im close to getting there myself but thought tutorials would be fun. itll get done either way but if you want to, you can write tutorials on developing bash and stuff and itll help everyone really
bash 4.4-rc1 EXECIGNORE not fully working?
$ type -a ls ls is /bin/ls $ # ls tab completion includes ls $ ls foo foo $ EXECIGNORE=/bin/ls $ type -a ls bash: type: ls: not found $ # ls tab completion does not include ls $ ls foo foo $ /bin/ls foo foo So ls is still executed despite the setting. I tried the same with /usr/bin/find and got the same result. GNU bash, version 4.4.0(1)-rc1 (x86_64-unknown-linux-gnu) -- Visit serverfault.com to get your system administration questions answered.
