Command not found with builtins and variables

2018-10-10 Thread bugs
Hi,
I'm not exactly sure if the following is actually a bug or whether bash
is actually supposed to behave like this. However, I couldn't find any
documentation concerning it so I decided to ask.

The thing I noticed is that when setting a variable and then running the
command "time", bash reports "command not found". For example, the
command:

TEST=1 time ls

Results in "bash: time: command not found"
At first, I believed that this was inherent to the bash builtins but I 
discovered
that

TEST=1 cd

Works without any problems, so I am confused as to why bash behaves in
this manner. Is there any underlying reason to this behaviour or is this
a bug?

cheers,
project-repo




Odd bash behaviour with time:

2014-10-31 Thread bugs

$ time;

real0m0.000s
user0m0.000s
sys 0m0.000s
$ time;ls
bash: syntax error near unexpected token `ls'
$ /usr/bin/time;/bin/ls 
Usage: /usr/bin/time [-apvV] [-f format] [-o file] [--append] [--verbose]

   [--portability] [--format=format] [--output=file] [--version]
   [--quiet] [--help] command [arg...]

It's the 2nd one that surprises me.
Why would time; succeed but time;anything fail  ?


--

Free Mickey!
http://randomfoo.net/oscon/2002/lessig/
http://www.law.duke.edu/cspd/comics/zoomcomic.html
My key: http://m8y.org/keys.html



Oddities when tab-completing filenames containing backticks

2009-10-15 Thread bash-bugs
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-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib   -g -O2 -Wall
uname output: Linux atu 2.6.27-14-generic #1 SMP Mon Aug 31 12:58:38 UTC 2009 
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.0
Patch Level: 39
Release Status: release

Description:
   
   Also affects Bash 4.0.33.
   
   When a filename begins with a backtick ` then tab-completion works
   as expected if you go \`, however if you try to tab-complete
   the filename inside single quotes, several strange behaviours appear.

Repeat-By:

   1) '`  This causes all commands available on the system to be
   listed such as `awk `bash etc., even though it's inside
   single quotes.

   2) '`text  This completes the filename, but it does not insert a
   trailing single quote as tab-completion would usually do.

   3) '`dir   This completes the directory name and adds the trailing
   forward slash, but not the trailing single quote.

   4) 'text`  This completes the filename and closes the single quote
   as expected.

   5) '`text' When using tab-completion inside single quotes on a
   filename beginning with a backtick, then it completes
   the filename and adds an additional closing single quote,
   e.g. '`filename.txt''

   6) '`dir'  When using tab-completion inside single quotes on a
   directory name beginning with a backtick, then it
   completes the directory name and adds an additional
   closing single quote after the directory name and before
   the forward slash, e.g. '`directory'/'








Re: Oddities when tab-completing filenames containing backticks

2009-10-17 Thread bash-bugs

2009/10/16 Chet Ramey :
> You need to remember that readline understands the characters in
> rl_completer_quote_characters as those which, in pairs, delimit quoted
> substrings in the line.  It performs completion (allowing the application
> to take first crack, of course) on the substring, using the text after
> the open quote.

Then it is a bug in readline that it is incapable of
properly handling nested quotes.

> The other thing to keep in mind is that readline doesn't look past point
> when performing completion -- it only considers characters from the
> beginning of the line or a quote character up to point.

If it considered characters from the beginning of the line,
then there would be no issue.  The backtick is inside an
open single quote, and the backtick is *not* a special
character under that circumstance -- it's no more special
to Bash than the letter "j" inside an open single quote.

> My answers below are for the built-in bash completion, not
> any programmable completions you might have defined.

I don't use any programmable completion, these are all stock,
and confirmed by other users of irc://irc.freenode.net/#bash

>> Repeat-By:
>>
>>1) '`  This causes all commands available on the system to be
>>listed such as `awk `bash etc., even though it's inside
>>single quotes.
>
> Readline does completion on substrings; it passes ` to the bash completion
> code, which performs command completion.

Again, a backtick is no more of a special character than the
letter "a" inside an open single quote.  This is incorrect
behaviour.

>>2) '`text  This completes the filename, but it does not insert a
>>trailing single quote as tab-completion would usually do.
>
> Bash receives "`text"

What do you mean by that?  Didn't you say Bash is sending
that to readline?

> does command completion on `text'

How would it do completion on something that isn't there?
I did not fill in a closing single quote.

> and suppresses the append of the close quote,
> since it's usually wrong in this case.

What appended closing quote, there is none?

If you go:

   # ls '/usr/bin/mpg3

You get the following:

   # ls '/usr/bin/mpg321'

But if you have a file called /tmp/`rubble.txt and go:

   # ls '/tmp/`rub

Then you get:

   # ls '/tmp/`rubble.txt

No closing single quote.  Incorrect and inconsistent
behaviour.  Inside single quotes, a backtick is no
different from any other character allowed in filenames,
including control characters, tabs, newlines, accented
letters, line-drawing characters, dashes, exclamation
points, etc.

Another example:

   # ls '/tmp/!rub

Completes as expected with the closing single quote for:

   # ls '/tmp/!rubble.txt'

The same goes for these filenames:

   # ls '/tmp/~test.txt'
   # ls '/tmp/"test.txt'
   # ls '/tmp/$test.txt'
   # ls '/tmp/-test.txt'
   # ls '/tmp/(test.txt'
   # ls '/tmp/&test.txt'

They all close the single quote.  The only one that
messes up is the filename beginning with a backtick.

>>3) '`dir   This completes the directory name and adds the trailing
>>forward slash, but not the trailing single quote.
>
> Again, appending the trailing single quote without the trailing ` is
> generally going to be wrong.

Please explain yourself.  Backticks *are not special* inside
single quotes.  Do you need a closing "h" if you have an
opening "h" in "hello world"?  No?  Then why would you need a
closing backtick which is just another normal character?  This
is obviously incorrect behaviour.

>>4) 'text`  This completes the filename and closes the single quote
>>as expected.
>
> Interesting.  I don't get this behavior.

This behaviour makes snese, because it is the correct
behaviour.  The other behaviour above is the incorrect
behaviour.  A backtick is *not* special to Bash from
inside single quotes.

>>5) '`text' When using tab-completion inside single quotes on a
>>filename beginning with a backtick, then it completes
>>the filename and adds an additional closing single quote,
>>e.g. '`filename.txt''
>
> Also interesting.  I get normal command completion without any closing
> quote appended.

Are you following my example exactly?  I'll provide
exact steps to reproduce, below.

Step 1:

   touch '/tmp/`example.txt'

Step 2:

   ls '/tmp/`exam'

Step 3:

   Place your cursor on top of the closing single quote,
   after the "m", and press 

Result:

   touch '/tmp/`example.txt''

Compare this to:

   touch '/tmp/example.txt'
   touch '/tmp/exam'
   touch '/tmp/example.txt'

Works as expected, no double-closing-single-quote.

>>6) '`dir'  When using tab-completion inside single quotes on a
>>directory name beginning with a backtick, then it
>>completes the directory name and adds an additional
>>closing single quote after the directory name an

Armenian Genocide Plagues Ankara 90 Years On

2005-05-15 Thread Zip-Bugs
Full Article:
http://service.spiegel.de/cache/international/0,1518,353274,00.html


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash