On 2/12/25 10:50 AM, Andrés Rodríguez Reina wrote:
Bash Version: 5.0
Patch Level: 17
Release Status: release
Description:
Due to a mistake in coding a script, a folder named '~' was generated. An
unexperienced bash user issued the command "rm -rf ~" by mistake, intending to
delete th
On 2/13/25 12:17 AM, Oğuz wrote:
Changes made to built-in printf have to be adopted by GNU printf, otherwise
the user will have two flavors of printf on the same system by the same
name. `-v varname' is irrelevant because it's obvious an external command
can't change the value of a shell variabl
On Thu, Feb 13, 2025 at 10:27 AM Oğuz wrote:
> And yes, I am sure; if built-in printf and GNU printf differ in common use
> cases that's a clear bug from the user's perspective.
>
There must be a bug somewhere then :-)
$ printf 1 2 3 4
1
$ /bin/printf 1 2 3 4
1/bin/printf: warning: ignoring ex
On Thu, Feb 13, 2025 at 08:17:45 +0300, Oğuz wrote:
> Changes made to built-in printf have to be adopted by GNU printf, otherwise
> the user will have two flavors of printf on the same system by the same
> name.
On Debian 12, /bin/echo (which is from GNU coreutils) and bash's builtin
echo do not s
On Thursday, February 13, 2025, Phi Debian wrote:
> '%(*)T\n'
>
GNU date already provides that functionality and is shipped alongside GNU
printf. It wouldn't be possible to implement the special argument -2 to
`%(datefmt)T' in an external utility anyway.
And yes, I am sure; if built-in printf a
On Thu, Feb 13, 2025 at 6:18 AM Oğuz wrote:
>
>
> Changes made to built-in printf have to be adopted by GNU printf, otherwise
> the user will have two flavors of printf on the same system by the same
> name.
> --
> Oğuz
>
You sure about the adopted by GNU printf assertion ?
$ /usr/bin/printf '%
