[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7463: truncate
From: |
Eric Blake |
Subject: |
bug#7463: truncate |
Date: |
Mon, 22 Nov 2010 08:48:29 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.6 |
On 11/22/2010 07:41 AM, Rupert Bruce wrote:
> truncate (GNU coreutils) 7.4
>
> Unexpected behavior:
>
> $ ls -l
> total 0
> $ truncate --size 0 *.log
> $ ls
> *.log
Thanks for the report. However, this is not a bug, but how the shell
works. By default, if a shell glob has no matches (in your case, there
are no files ending in .log in the current directory), then the glob is
passed as-is to the child process. And truncate assumes that when given
a file name that it should create that file.
>
> I would expect "truncate --size 0 *.log" to truncate any files ending
> with ".log"; instead I get a new file called "*.log"
Then your expectations need to be refined in light of standardized shell
globbing behavior.
Also, since you mentioned you use bash, you can change your shell
defaults. For example, 'shopt -s failglob' would make your above
command abort because no .log files were present, rather than passing
the unexpanded glob on as a filename. Likewise, 'shopt -s nullglob'
would make a non-matching glob silently result in no output (use with
caution; things like 'cat *.log' become a much different beast when
nullglob is enabled).
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature