Re: Could bash do what make does?
On Fri, Dec 02, 2016 Greg Wooledge wrote: "For starters, make is *older* than bash, by over a decade. "https://en.wikipedia.org/wiki/Make_%28software%29 says that make originated at Bell Labs in April 1976. "https://en.wikipedia.org/wiki/Bash_%28Unix_shell%29 says that the first "beta version of bash was released by Brian Fox in June 1989." But, quoting the second reference, bash is "a free software replacement for the Bourne shell" and the Bourne shell dates to 1977. Quoting the second reference, "before Make's introduction in 1976, the Unix build system most commonly consisted of operating system dependent make and install shell scripts accompanying their program's source." So it is not that much different from what I said. People would have known what the shell was good for when make appeared but they did not try to hold on to the build market which they had at that time.
Filename completion causes doubling of initial ':' character
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' -Wno-parentheses -Wno-format-security uname output: Linux genesis 4.4.33-1-MANJARO #1 SMP PREEMPT Fri Nov 18 18:06:44 UTC 2016 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.4 Patch Level: 5 Release Status: release Description: Given a filename called ':example' When the user enters 'command :' and hits Then the completion of the filename gets a doubled colon, specifically: ':\:example' Repeat-By: -- Create a filename beginning with a ':' character: $ touch :example Type `rm :` and hit tab, then enter. I'd expect to see: rm :example [rm silently deletes it] Instead I see: rm :\:example rm: cannot remove '::example': No such file or directory
Re: Filename completion causes doubling of initial ':' character
On Dez 03 2016, "Ravi (Tom) Hale" wrote: > Description: > > Given a filename called ':example' > When the user enters 'command :' and hits > Then the completion of the filename gets a doubled colon, specifically: > ':\:example' Make sure you don't have any custom completion functions (run complete -r) or non-default setting of COMP_WORDBREAKS. 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: Filename completion causes doubling of initial ':' character
On 12/3/16 6:41 AM, Ravi (Tom) Hale wrote: > Bash Version: 4.4 > Patch Level: 5 > Release Status: release > > > Description: > > Given a filename called ':example' > When the user enters 'command :' and hits > Then the completion of the filename gets a doubled colon, specifically: > ':\:example' > > > Repeat-By: > -- > Create a filename beginning with a ':' character: > > $ touch :example > > Type `rm :` and hit tab, then enter. > > I'd expect to see: > > rm :example > [rm silently deletes it] This has come up many times over the years. Here's one from 2003: http://lists.gnu.org/archive/html/bug-bash/2003-01/msg00088.html Question E13 in the Bash FAQ answers it. The short answer is that colon is special to readline: it breaks words for the readline completion code. If you want to complete filenames beginning with a colon, either quote the colon or remove colon from $COMP_WORDBREAKS. If you're using bash-completion, it may have its own problems with colons. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Could bash do what make does?
"build market"? What are you talking about? make was created with the sole purpose of build automation. The shell was created to provide a "human interface" to computer operators. These are very specific and different purposes. Are you going to start asking next to re-implement vi inside bash? to re-implement a mail user agent? a C compiler? Where do you draw the line? Read: http://www.catb.org/jargon/html/C/creeping-featurism.html I doubt anyone is willing to go through the effort to re-implement all the features that make provides, just because one guy thinks "it's obsolete" -- it's not, by the way. make is very alive. Also, it is part of the POSIX international standard. so any operating system that claims to be compatible with UNIX must provide it, see [1] and [2] and [3]. Also remember that nothing makes a stronger argument than patches. If you want to see this feature implemented, I suggest that you start looking into the features make provides, and send patches to add said functionality to bash. [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html [2] https://www.gnu.org/software/make/ [3] http://lists.gnu.org/archive/html/bug-make/
Re: command substitution bug
On 12/2/16 6:23 AM, parasite parasite wrote: > GNU bash, version 4.3.46(1)-release (x86_64-unknown-linux-gnu) > GCC: (GNU) 6.1.1 > On archlinux 4.4.27-1-lts > > Hello, today i tried something simple but it leads to what seems to be a bug. > > $ var="$(for ((i=0;i<$#;i++));do echo line;done)" > leads to: "unexpected EOF while looking for matching `)' > > I think it's because bash interprets "^#" as "#" which means that what > follow is commented. Thanks for the report. What happens is that bash skips over the `$' and assumes that the `#'' starts a word. An easy workaround is to precede the `$' with a space. I'll fix it in the next devel branch push. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash tests failing when compiled with --enable-xpg-echo-default=yes
On 12/1/16 5:44 PM, Vladimir Marek wrote: > Because of this setting the tests are failing. I am attaching a patch we > are using for workaround to show where the problems are seen. I used > 'echo -E' when investigating, but "printf '%s\n'" seems to be more > appropriate. If there is interest I'm more than happy to rework the > attached patch. Some combination of those two things and turning off xpg_echo at a script level should work. Note that `printf "%s\n"' is not equivalent to `echo -E' if more than one argument is supplied. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash tests failing when compiled with --enable-xpg-echo-default=yes
On 12/2/16 6:07 AM, Vladimir Marek wrote: > And second patch we use because of xpg-echo. Would it have sense to have > it included, or maybe stop the tests completely instead? You could just have turned off the xpg_echo option instead of going through a convoluted test (which just emulates `shopt -q') to determine whether or not it's on, but it does need to be off. This demonstrates just how incompatible echo is across shells. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Could bash do what make does?
On Sat, Dec 3, 2016 at 11:07 AM, Eduardo Bustamante wrote: > "build market"? What are you talking about? make was created with the > sole purpose of build automation. The shell was created to provide a > "human interface" to computer operators. These are very specific and > different purposes. Are you going to start asking next to re-implement > vi inside bash? to re-implement a mail user agent? a C compiler? Where > do you draw the line? Read: > OP must be confusing BASH with EMACS. > http://www.catb.org/jargon/html/C/creeping-featurism.html > > I doubt anyone is willing to go through the effort to re-implement all > the features that make provides, just because one guy thinks "it's > obsolete" -- it's not, by the way. make is very alive. Also, it is > part of the POSIX international standard. so any operating system that > claims to be compatible with UNIX must provide it, see [1] and [2] and > [3]. > > Also remember that nothing makes a stronger argument than patches. If > you want to see this feature implemented, I suggest that you start > looking into the features make provides, and send patches to add said > functionality to bash. > > [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html > [2] https://www.gnu.org/software/make/ > [3] http://lists.gnu.org/archive/html/bug-make/ > > -- Heisenberg may have been here. Unicode: http://xkcd.com/1726/ Maranatha! <>< John McKown
[4.4.5] trouble declaring readonly array variables
Hi,
upgraded bash from
GNU bash, version *4.3.30(1)-release* (x86_64-pc-linux-gnu)
to *4.4.5(1)-release* and noticed the *readonly* array variables fail to be
defined with init values.
See sample snippet:
o() {
local i j
readonly i=($1)
readonly j=(1 2 3)
echo "passed args expanded in arr declar: '${i[*]}'"
echo "args in an arr: '${j[*]}'"
}
$ o "a b c"
passed args expanded in arr declar: ''
args in an arr: ''
Platform:
Linux 8570w 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64
GNU/Linux
Is this a feature or a bug?
Thanks in advance,
Laur Aliste
