On 10/31/14, 5:15 AM, Sami Kerola wrote:
> On 30 October 2014 20:14, Eduardo A. Bustamante López
> wrote:
>>> Sounds the there is not much enthusiasm about making this sort of
>>> feature to work. This proposal belongs to archived never implemented
>>> ideas area. Good that effort wasting was kep
Chet Ramey wrote:
> * paste into the text editor invoked by the `edit-and-execute-command' key
> binding (C-xC-e in emacs mode), edit the command if desired, and have the
> shell automatically execute the contents of the editing buffer when the
> editor exits
Cool! This was an idea that I h
On 10/30/2014 06:05 AM, Bob Proulx wrote:
> Daniel Colascione wrote:
>> Well, I don't know whether Chet left the feature enabled by
>> default. I hope he did, though, since preventing execution of pasted
>> commands is one of the feature's key benefits. In bash, you should
>> be able to execute a p
> Sounds the there is not much enthusiasm about making this sort of
> feature to work. This proposal belongs to archived never implemented
> ideas area. Good that effort wasting was kept minimal.
Remember that working patches are better than just requesting
features. There are lots of pending featu
On 30 October 2014 20:14, Eduardo A. Bustamante López wrote:
>> Sounds the there is not much enthusiasm about making this sort of
>> feature to work. This proposal belongs to archived never implemented
>> ideas area. Good that effort wasting was kept minimal.
> Remember that working patches are be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/29/14, 9:58 PM, Marshall Giguere wrote:
> Bash Version: 4.2
> Patch Level: 25
> Release Status: release
>
> Description:
> Submitting a shell script job to "at" either via pipe, or
> command line fails.
It fails if you have exported functions
On 10/29/2014 07:58 PM, Marshall Giguere wrote:
> Description:
> Submitting a shell script job to "at" either via pipe, or
> command line fails.
The bug is not in bash, but in at. Furthermore, patches exist for
fixing at to properly ignore environment garbage (which is true whether
it is bash or
> OK. It doesn't sound like this feature is of general interest. Since
> you can control when you open and close file descriptors, you might look
> at $SECONDS when the file is opened and when it's closed and using the
> difference to see how long it was open.
If I understand correctly, the orig
On Wed, Oct 29, 2014 at 09:58:59PM -0400, Marshall Giguere wrote:
> Submitting a shell script job to "at" either via pipe, or
> command line fails.
Since you're posting this to b...@packages.debian.org I will assume
you're running Debian. This bug/misfeature of "at" was fixed in
the Debian packag
> Daniel Colascione wrote:
> > Well, I don't know whether Chet left the feature enabled by
> > default. I hope he did, though, since preventing execution of pasted
> > commands is one of the feature's key benefits. In bash, you should
> > be able to execute a pasted command sequence by typing RET a
2014-10-29 15:09 GMT+01:00 Sami Kerola :
>
> This idea came to my mind while writing a script that runs multiple
> commands, and I simply wanted to know how long they are busy. I am
> aware alternatives exist, but they can get a bit tricky if one wants to
> have multiple measurements going on simu
On Thu, Oct 30, 2014 at 1:45 PM, Daniel Colascione
wrote:
>
> Sure, you might argue that users should paste into a trusted
> intermediate location --- say a text editor --- inspect the code, and
> then paste into the shell. That would be the prudent thing to do, but
> users don't actually *do* th
On 10/30/2014 07:46 PM, Bob Proulx wrote:
> Chet Ramey wrote:
>> * paste into the text editor invoked by the `edit-and-execute-command' key
>> binding (C-xC-e in emacs mode), edit the command if desired, and have the
>> shell automatically execute the contents of the editing buffer when the
>>
On 30 Oct 2014 18:45, Daniel Colascione wrote:
+1
-mike
signature.asc
Description: Digital signature
$ 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]
[--qui
Hi,
it is actually built-in time that you run:
help time
if you want to run time from /usr/bin:
/usr/bin/time
cheers,
pg
On Fri, Oct 31, 2014 at 7:01 PM, wrote:
> $ time;
>
> real0m0.000s
> user0m0.000s
> sys 0m0.000s
> $ time;ls
> bash: syntax error near unexpected token `ls'
On Fri, Oct 31, 2014 at 11:00:22PM +0100, Piotr Grzybowski wrote:
> Hi,
>
> it is actually built-in time that you run:
Hm, read again. It is stated that the external command doesn't have
that issue. This is precisely related to the time builtin and why it
would cause a syntax error in this case.
On Fri, Oct 31, 2014 at 11:21 PM, Eduardo A. Bustamante López
wrote:
> Hm, read again. It is stated that the external command doesn't have
> that issue. This is precisely related to the time builtin and why it
> would cause a syntax error in this case.
Ola, ?que tal?
well, help time clearly sta
> well, help time clearly states how it should be used.
You are clearly not understanding the point.
The point is: why does
time
work, but
time ; somecommand
doesn't.
It's that simple. It's not a usage question, I'm very aware of how to
use time. Stop being condescending.
On Fri, 2014-10-31 at 15:56 -0700, Eduardo A. Bustamante López wrote:
> > well, help time clearly states how it should be used.
> You are clearly not understanding the point.
>
> The point is: why does
>
> time
>
> work, but
>
> time ; somecommand
>
> doesn't.
>
> It's that simple. It's
Hi Jon,
well, thats what I have been trying to say, before Eduardo almost killed me :)
help time clearly states that is requires a pipeline, NULL pipeline
is something that does not exist. it is just a bad usage of time
built-in.
cheers,
pg
On Sat, Nov 1, 2014 at 12:31 AM, jon wrote:
> On Fr
Hi Jon,
dedicated to you, (a bit trickier to find, since time is a static
shell builtin):
diff --git a/execute_cmd.c b/execute_cmd.c
index 9cebaef..47c6890 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -693,6 +693,10 @@ execute_command_internal (command, asynchronous, pipe_in, p
}
To Piotr:
On Sat, Nov 01, 2014 at 12:35:47AM +0100, Piotr Grzybowski wrote:
> well, thats what I have been trying to say, before Eduardo almost killed me
> :)
> help time clearly states that is requires a pipeline, NULL pipeline
> is something that does not exist. it is just a bad usage of time
> | When the shell is in posix mode, time may be followed by a newline. In
> this case, the shell displays the
> | total user and system time consumed by the shell and its children. The
> TIMEFORMAT variable may be used
> | to specify the format of the time information.
>
Two comments.
1)
On Oct 31, 2014, at 6:12 PM, jon wrote:
> Maybe it should be more like this:
>
> # time
> Error, 'time' with no arguments is only meaningful in posix mode
Or maybe like this (to be more like the standard BASH error format):
bash: time: an argument is required (POSIX mode enabled)
Sent from my
> Two comments.
>
> 1) The shell is not in posix mode.
Yep.
According to my tests, it also fails like OP reported in posix mode:
| dualbus@dualbus ~ % bash -c $'for ((i=0;i<1;i++)); do :; done\ntime'
|
| real0m0.000s
| user0m0.000s
| sys 0m0.000s
| dualbus@dualbus ~ % bash --pos
Sorry---I misunderstood.
Sent from my iPod
On Oct 31, 2014, at 6:40 PM, Ryan Cunningham wrote:
> On Oct 31, 2014, at 6:12 PM, jon wrote:
>
>> Maybe it should be more like this:
>>
>> # time
>> Error, 'time' with no arguments is only meaningful in posix mode
> Or maybe like this (to be more l
>But, the thing is... it shouldn't be a syntax error, right?
I agree, this thread is really about 2 issues. The interpreter barf
with "time;" and the fact that "time " is broken - I suspect
the two issues are not related.
> According to my tests, it also fails like OP reported in posix mode:
The
28 matches
Mail list logo
