Re: Avoid asterisk expansion when it selects "everything"
On 13 Apr 2016 11:23, Anis ELLEUCH wrote: > I would like to ask if it is possible to disable expanding asterisk when it > selects all entries ? > > `$ rm * .jpg` with a mistaken space between asterisk and .jpg will delete > everything in your home directory or in the entire disk. > > In my opinion, when the user asks to select "everything" which could be `*` > or `path/*`, bash has to show a confirmation prompt to check if the user > was not mistaken, this option should be obviously disabled by default > > Another idea: `*` and `/*` should not be interpreted and the user has to > enter another sequence "more powerful" to emphasize selecting all entries ( > `^*` would it work just fine ?) alternative idea: alias your rm/mv/etc... commands if you're worried about them. it's not uncommon to do in ~/.bashrc or wherever: alias rm='rm -i' then it's safe to `rm * .jpg`. for example: $ alias rm='rm -i' $ rm * rm: remove regular file ‘aaa’? ^C -mike signature.asc Description: Digital signature
Re: Avoid asterisk expansion when it selects "everything"
Anis ELLEUCH wrote: > I would like to ask if it is possible to disable expanding asterisk when it > selects all entries ? You ask if it is possible and the answer is no it is not possible. Because the shell expands the "*" before it passes the result as arguments to the rm command. The rm command has no idea it was the result of an expansion from a "*" wildcard. The rm command simply receives the list of files. > Another idea: `*` and `/*` should not be interpreted and the user has to > enter another sequence "more powerful" to emphasize selecting all entries ( > `^*` would it work just fine ?) But then the same thing exists there. If the user accidentally enters that sequence then it is the same thing all over again. If I am ever uncertain about a file glob expansion then I use echo first to see what the expansion will do. If dealing with dangerous commands such as rm then it is wise to check twice before invoking. echo rm * .jpg If you saw the result then you would fix it before invoking the command for effect. If the result is bad then correct it. If the result is good then remove the echo and run the command for effect. Bob
Re: Leak in BASH "named" file descriptors?
On 4/13/16 9:34 AM, Pierre Gaston wrote:
> For me the value is in 1) not hard coding the number and 2) being able to
> use more explicit names (eg "logfile" rather than "3"), nothing more.
If you limit the effects to those two, it's not a compelling feature to
add. In practice, the first is not a big problem if you're careful, and
the second can be trivially emulated with a single assignment statement.
> Of course if you use {var} for the redirections of an external command it's
> useless but not using a hard coded number can be useful if you use
> functions and don't want to have conflicts with someone else's function.
This is true, though bash does save and restore file descriptors where it
can if your hard-coded number is already in use.
> I don't really understand why using a symbolic name would need to provide
> more control, and in my opinion {var}> doesn't really provide something
> you can't do otherwise regarding the handling of the fd, it just has a
> different behavior.
It's an opportunity to provide more flexible behavior. The standard ways
to use file descriptors still exist, so if you don't like the different
behavior you have options.
--
``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 "while do echo" can't function correctly
On Wed, Apr 13, 2016 at 03:28:02PM +0100, Stephane Chazelas wrote: > 2016-04-13 08:55:16 -0400, Greg Wooledge: > [...] > > > And if you want to keep eventual spurious characters after the > > > last NL character in the file: > > > > > > while IFS= read -r line; do printf '%s\n' "$line"; done < test.txt > > > [ -z "$line" ] || printf %s "$line" > > > > Another way to write that is: > > > > while IFS= read -r line || [[ $line ]]; do ... done < test.txt > [...] > > Except that it would add an extra newline character (which may > be desired as well). I'm assuming you're using the input in some way, not just dumping it back out. If all you want is to dump the input back out to stdout, the correct way to write that is: cat In a loop that does something nontrivial to the input, treating each line of input as a data item to be processed after removing any trailing newlines, the way I wrote it is preferred because it lets you avoid writing the big complicated loop body twice. (Or moving the loop body to a function, which you then call from two different places.)
Re: bash "while do echo" can't function correctly
2016-04-13 08:55:16 -0400, Greg Wooledge: [...] > > And if you want to keep eventual spurious characters after the > > last NL character in the file: > > > > while IFS= read -r line; do printf '%s\n' "$line"; done < test.txt > > [ -z "$line" ] || printf %s "$line" > > Another way to write that is: > > while IFS= read -r line || [[ $line ]]; do ... done < test.txt [...] Except that it would add an extra newline character (which may be desired as well). -- Stephane
Re: Leak in BASH "named" file descriptors?
> On 4/13/16 1:54 AM, George Caswell wrote:
> > Personally, I don't think it makes sense for a redirection on a command to
> > persist beyond the scope of that command. A redirection with a
> > dynamically-assigned fd is basically equivalent to a redirection to a
> > numbered fd.
>
> Then why have it? There's not enough value in making a construct that
> is slightly different but functionally equivalent available unless it
> provides something new.
When paired with "exec" it does provide something new: dynamic file descriptor
allocation. This is the primary use case, and it helps make the code
legible and correct as the number of open files in the script grows.
When paired with another command, it's not as useful, because probably the set
of file descriptors you care about for a single command is much smaller than
the set of all file descriptors known to the shell. It's less likely you'll
need dynamic fd allocation in that case. As it stands this use case mainly
exists to keep the syntax consistent: You can use it with "exec" so you can use
it with other commands, too. Otherwise I don't think there's any benefit to it
in bash, ksh, or zsh at present.
But that's why I suggested a way that I think would make it consistent AND
useful: Make the variable binding accessible when the command string is
processed, and export it to the command's environment when it is run (assuming
it's not an array member or something): That way you can use the feature to
inform the command of where that file descriptor is and what it's for. Most
commands, if you hand them an extra file descriptor or two, won't know what to
do with it, or even bother to find out that it's there. They'll just leave it
open, ignorant of the fact that it is open. Usually if a command knows how to
use a file descriptor that's already open when it starts running, it has to be
told about it via command-line arguments.
(As a side note: IMO this is also a good reason why commands shouldn't get file
descriptors (other than 0,1,2) from the shell unless they're explicitly
connected via redirection syntax. Most processes will just be ignorant of the
extra file descriptors, and so the end result will be that the process will
keep the file descriptor open for its lifetime)
So in that case the value isn't so much the dynamic allocation aspect as the
fact that it maybe makes the shell code a bit cleaner: reinforces the
relationship between the redirection and the command line argument that
provides the file descriptor number to the command:
$ command --log-fd=9 --run-job 9>./logfile
versus
$ command --log-fd=${log_fd} --run-job {log_fd}>./logfile
Not a lot of commands support this kind of thing, but for the ones that do, it
could be useful. Much more useful IMO than the radical departure from normal
redirection rules that happens now. And it makes the meaning of the two forms
align nicely:
Using "exec 7
Avoid asterisk expansion when it selects "everything"
Hello everybody, I would like to ask if it is possible to disable expanding asterisk when it selects all entries ? `$ rm * .jpg` with a mistaken space between asterisk and .jpg will delete everything in your home directory or in the entire disk. In my opinion, when the user asks to select "everything" which could be `*` or `path/*`, bash has to show a confirmation prompt to check if the user was not mistaken, this option should be obviously disabled by default Another idea: `*` and `/*` should not be interpreted and the user has to enter another sequence "more powerful" to emphasize selecting all entries ( `^*` would it work just fine ?) Cordially, -- Sent from my mobile
Re: Leak in BASH "named" file descriptors?
On Wed, Apr 13, 2016 at 3:51 PM, Chet Ramey wrote:
> On 4/13/16 1:54 AM, George Caswell wrote:
>
> > Personally, I don't think it makes sense for a redirection on a command
> to
> > persist beyond the scope of that command. A redirection with a
> > dynamically-assigned fd is basically equivalent to a redirection to a
> > numbered fd.
>
> Then why have it? There's not enough value in making a construct that
> is slightly different but functionally equivalent available unless it
> provides something new.
>
>
For me the value is in 1) not hard coding the number and 2) being able to
use more explicit names (eg "logfile" rather than "3"), nothing more.
Of course if you use {var} for the redirections of an external command it's
useless but not using a hard coded number can be useful if you use
functions and don't want to have conflicts with someone else's function.
I don't really understand why using a symbolic name would need to provide
more control, and in my opinion {var}> doesn't really provide something
you can't do otherwise regarding the handling of the fd, it just has a
different behavior.
Re: Leak in BASH "named" file descriptors?
On 4/13/16 1:54 AM, George Caswell wrote: > Personally, I don't think it makes sense for a redirection on a command to > persist beyond the scope of that command. A redirection with a > dynamically-assigned fd is basically equivalent to a redirection to a > numbered fd. Then why have it? There's not enough value in making a construct that is slightly different but functionally equivalent available unless it provides something new. 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 "while do echo" can't function correctly
On Wed, Apr 13, 2016 at 01:43:42PM +0100, Stephane Chazelas wrote: > 2016-04-13 08:10:15 +0200, Geir Hauge: > [...] > > while read -r line; do echo "$line"; done < test.txt > > > > though printf should be preferred over echo: > > > > while read -r line; do printf '%s\n' "$line"; done < test.txt > [...] > > Actually, you also need to empty $IFS > > while IFS= read -r line; do printf '%s\n' "$line"; done < test.txt That will preserve every full line of input (except for the NUL bytes), including leading and trailing spaces. If you actually *want* the leading and trailing IFS whitespace characters to be trimmed (the default behavior of read), then do it Geir's way. In many cases, that's desired. > And if you want to keep eventual spurious characters after the > last NL character in the file: > > while IFS= read -r line; do printf '%s\n' "$line"; done < test.txt > [ -z "$line" ] || printf %s "$line" Another way to write that is: while IFS= read -r line || [[ $line ]]; do ... done < test.txt
Re: Memory leak in hc_erasedups
On 4/12/16 9:49 PM, Seiichi Ishitsuka wrote: > Hi all, > > I found memory leak in case of using "HISTCONTOL=erasedups" in bash-4.2. Thanks for the report. This will be fixed in the next release of bash. -- ``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 "while do echo" can't function correctly
2016-04-13 08:10:15 +0200, Geir Hauge: [...] > while read -r line; do echo "$line"; done < test.txt > > though printf should be preferred over echo: > > while read -r line; do printf '%s\n' "$line"; done < test.txt [...] Actually, you also need to empty $IFS while IFS= read -r line; do printf '%s\n' "$line"; done < test.txt And if you want to keep eventual spurious characters after the last NL character in the file: while IFS= read -r line; do printf '%s\n' "$line"; done < test.txt [ -z "$line" ] || printf %s "$line" For details, see: https://unix.stackexchange.com/questions/209123/understand-ifs-read-r-line https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo https://unix.stackexchange.com/questions/169716/why-is-using-a-shell-loop-to-process-text-considered-bad-practice -- Stephane
Re: bash "while do echo" can't function correctly
On Wed, Apr 13, 2016 at 06:49:51AM -0500, John McKown wrote: > ???Ah. Thanks. I only use BASH and the GNU infrastructure, so I have never > run into that problem. I think I'll change my habits, just in case I run > across a system which doesn't have it (especially in my scripts) Every implementation of echo has *some* input on which it fails, including bash's implementation. imadev:~$ type echo echo is a shell builtin imadev:~$ x=-n imadev:~$ echo "$x" imadev:~$ printf '%s\n' "$x" -n You simply hadn't run into any of the failure cases yet.
Re: bash "while do echo" can't function correctly
On Wed, Apr 13, 2016 at 6:45 AM, Pierre Gaston
wrote:
>
>
> On Wed, Apr 13, 2016 at 2:34 PM, John McKown > wrote:
>
>> On Wed, Apr 13, 2016 at 1:10 AM, Geir Hauge wrote:
>>
>> ...
>>
>>
>>> though printf should be preferred over echo:
>>>
>>> while read -r line; do printf '%s\n' "$line"; done < test.txt
>>>
>>
>> I've never read about using printf in preference to echo. Why is that?
>> I have used it myself in special cases, such as wanting leading zeros
>> (i=0;printf '%03d\n' "${i}";)
>>
>
>
> Posix says:
>
> It is not possible to use *echo* portably across all POSIX systems unless
> both *-n* (as the first argument) and escape sequences are omitted.
> The *printf*
>
> utility can be used portably to emulate any of the traditional behaviors of
> the *echo* utility as follows (assuming that *IFS* has its standard value
> or is unset)
>
Ah. Thanks. I only use BASH and the GNU infrastructure, so I have never
run into that problem. I think I'll change my habits, just in case I run
across a system which doesn't have it (especially in my scripts)
--
How many surrealists does it take to screw in a lightbulb? One to hold the
griffon and one to fill the bathtub with brightly colored LEDs.
Maranatha! <><
John McKown
Re: bash "while do echo" can't function correctly
On Wed, Apr 13, 2016 at 2:34 PM, John McKown
wrote:
> On Wed, Apr 13, 2016 at 1:10 AM, Geir Hauge wrote:
>
> ...
>
>
>> though printf should be preferred over echo:
>>
>> while read -r line; do printf '%s\n' "$line"; done < test.txt
>>
>
> I've never read about using printf in preference to echo. Why is that? I
> have used it myself in special cases, such as wanting leading zeros
> (i=0;printf '%03d\n' "${i}";)
>
Posix says:
It is not possible to use *echo* portably across all POSIX systems unless
both *-n* (as the first argument) and escape sequences are omitted.
The *printf*
utility can be used portably to emulate any of the traditional behaviors of
the *echo* utility as follows (assuming that *IFS* has its standard value
or is unset)
Re: bash "while do echo" can't function correctly
On Wed, Apr 13, 2016 at 1:10 AM, Geir Hauge wrote:
...
> though printf should be preferred over echo:
>
> while read -r line; do printf '%s\n' "$line"; done < test.txt
>
I've never read about using printf in preference to echo. Why is that? I
have used it myself in special cases, such as wanting leading zeros
(i=0;printf '%03d\n' "${i}";)
>
> --
> Geir Hauge
>
>
--
How many surrealists does it take to screw in a lightbulb? One to hold the
griffon and one to fill the bathtub with brightly colored LEDs.
Maranatha! <><
John McKown
Re: Leak in BASH "named" file descriptors?
> On 1/27/16 1:18 PM, Mathieu Patenaude wrote:
> >
> > When using "named" file descriptors inside a function, the file descriptors
> > are not automatically un-linked when the function returns, but when using
> > regular "numbered" file descriptors they are automatically "destroyed".
>
> Yes. That's the intent. The idea is that if you assign a variable, you
> have a `handle' on the file descriptor and can manage it yourself.
In other words, the file redirection persists because the variable persists...
But what if that weren't the case? What if, instead, the rule were "the
variable binding doesn't persist because the file redirection doesn't
persist"?
Perhaps that could be used to do things like this:
$ xterm -Sblah/$p {p}<>ttyfile
In other words, in this hypothetical case the value $p is made available to
perform substitutions in the command it's being applied to, and both the
variable $p an the file descriptor it represents are limited in scope to this
one command, as if running something like this:
$ ( exec {p}<>ttyfile; export p; xterm -Sblah/$p )
Personally, I don't think it makes sense for a redirection on a command to
persist beyond the scope of that command. A redirection with a dynamically-
assigned fd is basically equivalent to a redirection to a numbered fd. The two
should behave similarly.
---GEC
