Re: Odd bash behaviour with time:
>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 OP reported the syntax error, I reported that time noargs always returns zero, IE it is broken. > Or... why not have time behave the same in non-posix mode?... > backwards compatibility is not an issue, since it's not useful right > now. And the posix mode behavior is kind of useful. I disagree, time with no arguments is a confusing idea. Time as a command is quite intuitive, but time with arguments is not - most people would have to refer to the documentation to confirm what it actually measures. As it it appears to measure nothing at all, and I believe a slightly broken concept, then my personal preference would be to remove the "time " behaviour completely. All but the most marginal real world cases can be tested like this: # time /bin/bash -c 'somescript or command' Even the loading setup time of bash itself can be tested like this: # time /bin/bash -c 'exit' It is better to have any real world script using time with no arguments exit with an error in the future rather than report that everything is a super computer as it does currently.
Re: Odd bash behaviour with time:
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 like the standard BASH error format): > > bash: time: an argument is required (POSIX mode disabled) > > Sent from my iPod
Re: Odd bash behaviour with time:
> 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 --posix -c $'for ((i=0;i<1;i++)); do :; done\ntime' | user0m0.06s | sys 0m0.00s | dualbus@dualbus ~ % bash --posix -c $'head -c100 /dev/null\ntime' | user0m0.00s | sys 0m0.09s | dualbus@dualbus ~ % bash -c $'head -c100 /dev/null\ntime' | | real0m0.000s | user0m0.000s | sys 0m0.000s | dualbus@dualbus ~ % bash -c $'time;ls' | bash: -c: line 0: syntax error near unexpected token `ls' | bash: -c: line 0: `time;ls' | dualbus@dualbus ~ % bash --posix -c $'time;ls' | bash: -c: line 0: syntax error near unexpected token `ls' | bash: -c: line 0: `time;ls' > 2) In non posix mode time with no arguments is not meaningful. Best I > can tell it always returns 0, I still maintain it should return an > error. > > # while :; do echo Hello; done > Let it run and run and run > # ^C > # time > > real0m0.000s > user0m0.000s > sys 0m0.000s > > > > Maybe it should be more like this: > > # time > Error, 'time' with no arguments is only meaningful in posix mode I agree with you on this. But, the thing is... it shouldn't be a syntax error, right? My opinion is that $ time bash: usage error: blah blah $ time; ls bash: usage error: blah blah foo bar baz Should be how bash treats this, even if time is a special keyword. Or... why not have time behave the same in non-posix mode?... backwards compatibility is not an issue, since it's not useful right now. And the posix mode behavior is kind of useful.
Re: Odd bash behaviour with time:
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 iPod
Re: Odd bash behaviour with 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) The shell is not in posix mode. 2) In non posix mode time with no arguments is not meaningful. Best I can tell it always returns 0, I still maintain it should return an error. # while :; do echo Hello; done Let it run and run and run # ^C # time real0m0.000s user0m0.000s sys 0m0.000s Maybe it should be more like this: # time Error, 'time' with no arguments is only meaningful in posix mode
Re: Odd bash behaviour with time:
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 > built-in. Can you cut the crap? It's you not understanding the question and pretending that you do. Also, don't send mail to me privately. I don't take back the condescending part, because that's what you're doing, pretending that you know more than the OP and I, without even actually researching what's being discussed. It would be better if you just stepped back, and waited for Chet's reply, who is the only one who has something interesting to say about this. Also, quit the broken Spanish and the references to killing. That's very distasteful. Evidently, you haven't read the manual: | 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. That is: time\n Hint: it's not followed by a pipeline. It doesn't say about bash not running in posix mode, but, I'd expect that to be the same behavior. To jon: > > Interesting interpreter question, but does "time" on its own have any > > meaning? - if not "time" with no arguments should generate an error > > rather than an output as it does currently. I agree, if time doesn't generate an error, why time; command does... That's a question for Chet to answer, or by someone that understands what the parser is doing here.
Re: Odd bash behaviour with time:
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
}
else
{
+ if (command == NULL || (command->type == cm_simple && command->value.Simple-
+printf("\nnecesitamos un pipeline\n");
+return 1;
+ }
exec_result = time_command (command, asynchronous, pipe_in, pipe_out,
#if 0
if (running_trap == 0)
On Sat, Nov 1, 2014 at 12:31 AM, jon wrote:
> 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 not a usage question, I'm very aware of how to
>> use time. Stop being condescending.
>
> Interesting interpreter question, but does "time" on its own have any
> meaning? - if not "time" with no arguments should generate an error
> rather than an output as it does currently.
>
>
> This is meaningful
> # time /bin/bash -c 'sleep 1' ;echo hello
>
> real0m1.003s
> user0m0.004s
> sys 0m0.000s
> hello
>
> This is not
> # time ;echo hello
> bash: syntax error near unexpected token `echo'
>
>
Re: Odd bash behaviour with time:
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 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 not a usage question, I'm very aware of how to >> use time. Stop being condescending. > > Interesting interpreter question, but does "time" on its own have any > meaning? - if not "time" with no arguments should generate an error > rather than an output as it does currently. > > > This is meaningful > # time /bin/bash -c 'sleep 1' ;echo hello > > real0m1.003s > user0m0.004s > sys 0m0.000s > hello > > This is not > # time ;echo hello > bash: syntax error near unexpected token `echo' > >
Re: Odd bash behaviour with time:
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 not a usage question, I'm very aware of how to > use time. Stop being condescending. Interesting interpreter question, but does "time" on its own have any meaning? - if not "time" with no arguments should generate an error rather than an output as it does currently. This is meaningful # time /bin/bash -c 'sleep 1' ;echo hello real0m1.003s user0m0.004s sys 0m0.000s hello This is not # time ;echo hello bash: syntax error near unexpected token `echo'
Re: Odd bash behaviour with time:
> 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.
Re: Odd bash behaviour with time:
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 states how it should be used. cheers, pg
Re: Odd bash behaviour with time:
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.
Re: Odd bash behaviour with time:
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' > $ /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 >
Odd bash behaviour with time:
$ 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
Re: [PATCH] bracketed paste support
On 30 Oct 2014 18:45, Daniel Colascione wrote: +1 -mike signature.asc Description: Digital signature
Re: [PATCH] bracketed paste support
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 >> editor exits > > Cool! This was an idea that I hadn't thought about before. (I often > would paste into my editor and clean it up. But doing it as part of > the edit-and-execute-command is very nice!) > > Thanks for this hint! Be careful with this though as the editor may be more exploitable. I see vim for example interprets even in paste mode. It probably shouldn't do that in paste mode, but you can see what happens if you paste from the following innocuous looking HTML page: printf 'echo \033:q!ls' > t.html This just runs the "q" command, but could be anything of course. Pádraig.
Re: [PATCH] bracketed paste support
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* that and never will. > > > And you have communities whose idea of an installer is wget | bash. I'm looking at you [redacted].
Re: feature: time builtin and file descriptor
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 simultaneously. For example:
>
> exec 42>&0
> time --file-descriptor 42
> for i in items; in
> exec 52>&0
> time --file-descriptor 52
> echo "processing $i"
> [...]
> echo "item $i took"
> exec 52>&-
> done
> echo 'all together took:'
> exec 42>&-
>
You could achieve this by using command grouping and TIMEFORMAT:
items=( a b c )
time {
for i in "${items[@]}"; do
time {
echo "processing $i"
sleep "$((RANDOM%5 + 1))"
TIMEFORMAT="item $i took %R seconds"
}
done
TIMEFORMAT='all together took: %R seconds'
}
example output:
processing a
item a took 5.001 seconds
processing b
item b took 1.001 seconds
processing c
item c took 3.001 seconds
all together took: 9.004 seconds
It would be prettier if TIMEFORMAT could be set on invocation of time,
e.g. TIMEFORMAT='foo took %R seconds' time { ...; } , but time being a
keyword probably makes that hard.
One also has to be careful to sanitize any variables one embeds in
TIMEFORMAT since % characters are special.
--
Geir Hauge
Re: [PATCH] bracketed paste support
> 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 after the > > paste, but a paste by itself should never begin execution. > > I use paste into the shell with an embedded newline in order to > immediately execute a command *a lot*. If that were removed I would > be very unhappy. There are a number of strategies you can employ if you're closer to Daniel than Bob on this and you want to avoid executing pasted shell commands with the current version of bash. Even if you don't want to change your selection habits to avoid selecting the entire line, there are a few things you can do: * configure your terminal emulator, if possible, to remove trailing newlines in pasted text * paste into a text editor running in a separate window, edit the command if desired, then re-select and re-paste into your terminal window * 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 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 ShellShock patches break "at" job submission of bash scripts
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 package of "at" version 3.1.13-2+deb7u1 on September 30. >From the changelog.Debian.gz file: at (3.1.13-2+deb7u1) wheezy; urgency=medium * at: Only retain variables whose name consists of alphanumerics and underscores. This prevents jobs from failing in case bash exports functions to the environment with the changes from DSA-3035. -- Ansgar Burchardt Tue, 30 Sep 2014 20:58:23 +0200
Re: feature: time builtin and file descriptor
> 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 original issue wasn't exactly to
measure the time FDs were open, but to use that measure to time the
execute of code blocks. That is, timing open FDs was just a tool, not
the goal itself. Since we can already time blocks, I think this
alternative is not needed. I wrote a detailed explanation here:
dualbus@hp:~$ bash ./script
processing $i=1
item $i=1 took 4.003
processing $i=2
item $i=2 took 6.003
processing $i=3
item $i=3 took 8.003
all together took 18.014
dualbus@hp:~$ cat ./script
#!/bin/bash
# set TIMEFORMAT to show only the 'elapsed time in seconds'. (see man bash)
TIMEFORMAT=%R
# The key points are:
# 1. You can 'time' a block, so, stuff like: time { ...; } and time for ...; do
...
#are valid. You don't need to trace an open file descriptor to time a block
#of commands.
# 2. Capturing the output of 'time' is tricky, but it can be done, follow the
#indications here: http://mywiki.wooledge.org/BashFAQ/032 (or read my
#attempt at explaining it at the end)
{ g=$(
{ time for i in 1 2 3; do
echo "processing \$i=$i"
{ t=$(
{ time {
# item commands
sleep "$i"
sleep "$((i+2))"
}
} 2>&1 >&3
);} 3>&1
echo "item \$i=$i took $t"
done
} 2>&1 >&3
);} 3>&1
echo "all together took $g"
# How to do what I think you want to do:
#
# 1. Change TIMEFORMAT to output just the number you want (easy)
# 2. Now, the tricky part, capture the output of time:
#- You can't just do: var=$(time ...) and hold the output of time in var,
# because 'time' writes to stderr. So the logical thing follows.
#- We try: var=$(time ... 2>&1 >/dev/null) (we discard stdout for
# simplicity), but that still doesn't work, because that redirection
# doesn't seem to apply to 'time', instead, it applies to the command
# we're timing.
#- So, we try: var=$({ time ...; } 2>&1 >/dev/null), and... that works.
# By doing the redirection on a group that consists only of 'time', we
# managed to capture its output.
#
# You can try this at home:
#
# $ TIMEFORMAT=%R; var=$({ time sleep 3.1416;} 2>&1 >/dev/null); echo "$var"
# 3.143
#
# 3. So, we have the elapsed time... but, what if we also want to keep stdout?
#We have to do some tricky redirections:
#
#{ var=$({ time ...; } 2>&1 >&3); } 3>&1
#
#Don't panic, it looks horrible, but it's actually easy to understand. The
#first thing we should know is that redirections apply following these two
#rules:
#
#a. If you have nested blocks, it will apply the outer redirections first.
# So, in { { { foo >a; } >b; } >c; } >d
# It will first redirect to 'd', then to 'c', then to 'b', ...
#b. Redirections done at the same level are executed from left to right.
#
#With these two details we can proceed to understand:
#
#{ var=$({ time ...; } 2>&1 >&3); } 3>&1
#
#Since we execute the outer redirections first, '3>&1' is the first
#redirection, so now there's a file descriptor 3, open for the whole block
#delimited by { ... }. Ah, and that FD3 is a clone of the script's stdout,
#which could be a file, the terminal, etc. Then, inside var=$({...} redirs)
#we have another set of redirections, '2>&1' and '>&3'. They get executed
#from left to right, so '2>&1' goes first. What this does is to send stderr
#(time's output), to stdout *but* in this case, stdout goes to $(...),
#which is captured in 'var' (it doesn't go to the main script stdout). And
#then we have '>&3', which does: send stdout (which currently was going to
#$(...) ) to the main script's stdout (&3 is a clone of it).
#
#Sorry for the complex explanation.
#
#And, if I read your original email correctly, this is what you wanted to
do:
#
# > 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
#
#So, now you can run 'time' multiple times, even nested, and find out how
#long they are busy, without having to patch bash. (Sure, the code is ugly,
#but, it's bash, it's expected to be like that ;) ).
#
# > What do you think, useful feature or unnecessary bloat?
# My opinion is: unnecessary bloat, since we can work-around that specific
# case without new features. Sure, the work-around is ugly, but, it's
# consistent, and, with a bit of effort, it can do almost everything your
# proposal attempts to achieve.
Re: Bash ShellShock patches break "at" job submission of bash scripts
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 something else generating the environment garbage). http://anonscm.debian.org/cgit/collab-maint/at.git/commit/?id=482f5962d -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Bash ShellShock patches break "at" job submission of bash scripts
-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 in your environment. This is a bug in `at': specifically, its assumption that every string that appears in the environment is a valid shell identifier. This was never a valid assumption to make, but now that exported functions use characters outside the identifier namespace it's become more apparent. The problem is amplified by the fact that dash is reacting poorly to whatever `at' is trying to do to format the environment strings as assignment statements. I believe that the upstream `at' developer is working on a fix. 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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iEUEARECAAYFAlRST1gACgkQu1hp8GTqdKsqZgCfVgW688lpx7NNTDrRlQyCp15C PvkAl2TTvqdsoRh9r6+tnKk6QXQ3FNM= =i5Yh -END PGP SIGNATURE-
Re: feature: time builtin and file descriptor
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 better than just requesting > features. There are lots of pending features that are requested more > frequently, so that's a lot of work for a single person to handle. I prefer first getting understanding if a feature is wanted, before starting to hack too much. My time has value to me. I don't want to spend it in writing a change that will be rejected. Neither I want to spend maintainer time to go through that sort of stuff. In other words; fail as fast & cheap way as possible is a good workflow. -- Sami Kerola http://www.iki.fi/kerolasa/
Re: feature: time builtin and file descriptor
> 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 features that are requested more frequently, so that's a lot of work for a single person to handle.
Re: [PATCH] bracketed paste support
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 pasted command sequence by typing RET after the >> paste, but a paste by itself should never begin execution. > > I use paste into the shell with an embedded newline in order to > immediately execute a command *a lot*. If that were removed I would > be very unhappy. I strongly doubt that your use case is typical. I've asked several of my colleagues; all have complained about accidentally pasting a large amount of text into the shell at one time or another. Nobody has complained about losing automatic execution of code after paste. Speaking from personal experience, I've been using terminal emulators of various sorts for almost 20 years, and in that time, I've accidentally pasted documents into my terminal orders of magnitude more often than I've deliberately pasted multi-command sequences. As far as I'm concerned, automatic execution of code on paste isn't a feature: it's a bug and security hole. Users should have to opt into security holes. We've only lived with the existing behavior so long because it's only recently become possible to distinguish pastes from other input. > However I read from Chet's replies that this is not the case. So I am > not worried. Just voicing a counter opinion that this shouldn't be > removed. Nobody is talking about removing the ability to select the present behavior. We're talking about the default setting. > If you want it then you should enable it. This is like many > other options available in the shell. They are optional. This feature significantly decreases the likelihood of user error, but if it's not on by default, most users won't enable it and won't see any benefits. I'd rather slightly power users like you with very specific use cases than continue to see accidental code execution. >> For better or worse, people copy and paste commands from websites >> all the time. Even if a bit of shell looks innocuous, a malicious >> bit of JavaScript could change the pasted text at the last second >> without the user being aware of the switch. > > Then the browser shouldn't copy it. The place to fix the problem is > in the browser. Browser behavior is unlikely to change; even if it did, sequences of text that look safe can contain control characters like TAB that invoke various shell commands. Visually inspection is not a reliable way to inspect a piece of code pasted from an otherwise-untrusted source. 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* that and never will. > A problem with a browser should not break cutting and > pasting in general. This change doesn't "break" pasting. It changes its behavior to one that's safer, more natural, and more consistent with that of other programs. >> (Tynt uses this technique to slightly less malicious ends.) If >> pasting in a terminal immediately begins execution, there's no >> opportunity to review pasted code. With bracketed paste support, the >> shell requires additional user interaction after a paste to begin >> execution, making this attack much less effective. > > I am very happy this is a feature you like. However I would hate that > feature. It should definitely not default to on or it will make > people like me very unhappy. You can disable the setting yourself. If you don't want to do that, all you need to do is type RET after pasting. That's a very small tradeoff for an increase in safety and predictability. signature.asc Description: OpenPGP digital signature
Re: [PATCH] bracketed paste support
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 hadn't thought about before. (I often would paste into my editor and clean it up. But doing it as part of the edit-and-execute-command is very nice!) Thanks for this hint! Bob
Re: feature: time builtin and file descriptor
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 kept minimal. >> Remember that working patches are better than just requesting >> features. There are lots of pending features that are requested more >> frequently, so that's a lot of work for a single person to handle. > > I prefer first getting understanding if a feature is wanted, before > starting to hack too much. My time has value to me. I don't want to > spend it in writing a change that will be rejected. Neither I want to > spend maintainer time to go through that sort of stuff. In other > words; fail as fast & cheap way as possible is a good workflow. 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. 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/
