Re: Full-width characters can result in an unwanted space in filenames

On 3/6/17 2:11 PM, Misaki wrote: > At the risk of annoying people, I am replying to all. > > If a filename is displayed with 'ls', an extra space won't be copied if you > highlight and copy it (including middle-click paste/X selection). Is it not > possible to have user input work the same way?

Re: Pipe using subshells, variables not saved

On 3/6/17 2:44 PM, Misaki wrote: > > On Sat, Mar 4, 2017 at 10:12 AM, Chet Ramey > wrote: > > On 3/4/17 1:04 AM, Misaki wrote: > > Variables are not saved when using a pipe because both sides are in a > > subshell environment. > > If you want this to

Re: Pipe using subshells, variables not saved

On Sat, Mar 4, 2017 at 10:12 AM, Chet Ramey wrote: > On 3/4/17 1:04 AM, Misaki wrote: > > Variables are not saved when using a pipe because both sides are in a > > subshell environment. > > If you want this to happen, enable the `lastpipe' shell option. > Thank you. My standpoint is 'whatever ma

Re: Full-width characters can result in an unwanted space in filenames

On Sun, Mar 5, 2017 at 9:39 AM, L A Walsh wrote: > Chet Ramey wrote: > >> On 3/4/17 12:53 AM, Misaki wrote >> >>> Full-width character, followed by at least one full word with a space >>> after it. >>> >>> Example: あa a >>> With trailing space. >>> >>> >> >> This is a display artifact. If there i

Re: Full-width characters can result in an unwanted space in filenames

On Sat, Mar 4, 2017 at 11:54 AM, Chet Ramey wrote: > On 3/4/17 12:53 AM, Misaki wrote: > > > 15 Mar 2015 > > bash bug > > Full-width character, followed by at least one full word with a space > after it. > > > > Example: あa a > > > > With trailing space. > > > > Typing before the full-width chara

Re: -eq and strings

On 06-03-17 16:09, Geir Hauge wrote: > If you're counting milliseconds, pattern matching should be slightly > faster than your -eq hack. Without benchmarks, I'll take your word for this. But this really convinced me: > See also http://mywiki.wooledge.org/BashFAQ/054 "this method fails if the sh

Re: -eq and strings

On Mon, Mar 06, 2017 at 03:31:31PM +0100, Rob la Lau wrote: > On 06-03-17 15:16, Reuti wrote: > > if ! expr "$x" : '[[:digit:]]*$' >/dev/null; then echo no; fi > > > > if [ -n "${x//[0-9]/}" ]; then echo no; fi > > True, but regular expressions are usually considered expensive. > (Must admit I ne

Re: -eq and strings

On 6 March 2017 14:09:39 GMT+00:00, Rob la Lau wrote: >On 06-03-17 14:18, Greg Wooledge wrote: >> You're misunderstanding. In a math context, which you are creating >here >> by using -eq, the word 'x' is interpreted as a variable name, which >may >> contain another variable name, and so on, until

Re: Problem: completion changes user-relative path into absolute path breaking relative-path usages

Chet Ramey wrote: I can't reproduce this with bash-4.4, even when setting `direxpand' before performing completion on a pathname beginning with `../'. It is possible that you or your vendor compiled bash with directory expansion enabled by default (--enable-direxpand-default), which turns this

Re: Bug: UTF-8 expansion results in extra characters

Eduardo Bustamante wrote: On Mon, Mar 6, 2017 at 6:50 AM, L A Walsh wrote: [...] echo 'あa a '|wc -m 6 There should only be 5 characters. use echo -n then. $ echo -n 'あa a '|wc -m 5 --- Yup. I'm an idiot at times! The thing was that I kept copying it into differen

Re: Problem: completion changes user-relative path into absolute path breaking relative-path usages

On 3/6/17 7:33 AM, L A Walsh wrote: > Under 4.4: > > Ishtar:../util-linux-2.29.2> mydiff ../conf > Ishtar:../util-linux-2.29.2> mydiff > /home/tools/util-linux/year-/month-mmm/day-ddd/newwork/very_long_path/config-2292.sh > > diff: > /home/tools/util-linux/year-/month-mmm/day-ddd/newwork

Re: -eq and strings

On 06-03-17 15:16, Reuti wrote: > if ! expr "$x" : '[[:digit:]]*$' >/dev/null; then echo no; fi > > if [ -n "${x//[0-9]/}" ]; then echo no; fi True, but regular expressions are usually considered expensive. (Must admit I never benchmarked.) And I know 1 regex won't considerably slow down my scri

Re: -eq and strings

> Am 06.03.2017 um 15:09 schrieb Rob la Lau : > > On 06-03-17 14:18, Greg Wooledge wrote: >> You're misunderstanding. In a math context, which you are creating here >> by using -eq, the word 'x' is interpreted as a variable name, which may >> contain another variable name, and so on, until final

Re: Bug: UTF-8 expansion results in extra characters

On Mon, Mar 6, 2017 at 6:50 AM, L A Walsh wrote: [...] > echo 'あa a '|wc -m > 6 > > There should only be 5 characters. use echo -n then. $ echo -n 'あa a '|wc -m 5

Re: -eq and strings

On 06-03-17 14:18, Greg Wooledge wrote: > You're misunderstanding. In a math context, which you are creating here > by using -eq, the word 'x' is interpreted as a variable name, which may > contain another variable name, and so on, until finally an integer is > discovered. Thanks. Now that I know

Re: unset array[0] doesn't delete the element

On Sat, Mar 04, 2017 at 09:10:00PM -0800, Isaac Good wrote: > Repeat-By: > $ arr=(1 2 3); unset arr[-1]; echo "${arr[@]}" > 1 2 3 On Sat, Mar 04, 2017 at 09:14:09PM -0800, Isaac Good wrote: > Bug report being withdrawn. I had nullglob set so unset wasn't being > invoked properly. The

Re: -eq and strings

On Sat, Mar 04, 2017 at 01:15:58PM +0100, Rob la Lau wrote: > Looking a bit further: it doesn't do any comparison on the given strings: > > $ [[ "x" -eq "y" ]] && echo "yes" || echo "no" > yes You're misunderstanding. In a math context, which you are creating here by using -eq, the word 'x' is i

Re: Pipe using subshells, variables not saved

On Fri, Mar 03, 2017 at 10:04:23PM -0800, Misaki wrote: > > reason for piping: > > echo wat | for i in $(< /dev/stdin); do declare -g new="$i"; done > > > > (using find instead of echo, not sure if better way to loop) while IFS= read -r file; do blah "$file"; done < <(find . -type f) That's compa

Bug: UTF-8 expansion results in extra characters

I didn't see that this was caught and wasn't sure if it was already covered in what I previously posted this problem in a follow-up to a similar problem. It may be the same bug, but I wasn't sure. If I past the text in quotes into bash, bash tosses in an extra character as evidenced by 'wc':

Problem: completion changes user-relative path into absolute path breaking relative-path usages

I have used relative paths to a 'base' and 'dest' to allow comparisons/upgrades, etc, something along the lines of (this is a rough-spur of the moment example): cur=where I'm currently working base=olddir ... idea that no matter where I move in new tree, path from 'cur' is same as path from 'bas