Re: [PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

[Chet Ramey]

On 6/4/24 2:10 AM, konsolebox wrote:


I haven't looked at this but it will keep lazy functions safe to
implement right?


Yes.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

[Koichi Murase]

2024年6月4日(火) 15:11 konsolebox :
> I haven't looked at this but it will keep lazy functions safe to
> implement right?

Right. The fix shouldn't change the observable behavior.

The functions are saved in two hash tables, `shell_functions' and
`shell_function_defs'. The function bodies are supposed to be put in
the former hash table, and the metadata (the source-file location and
the line where it is defined) are supposed to be put in the latter
hash table. However, we reuse the data structure for the function
declaration (containing both bodies and metadata) to keep the
metadata, and the function bodies were also contained in the latter
hash table unintentionally. We've been saving the data that has never
been used.

--
Koichi

Re: [PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

[konsolebox]

On Sat, Jun 1, 2024 at 7:16 PM Koichi Murase  wrote:
>
> ---
>  variables.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/variables.c b/variables.c
> index 84b30d93..0e785742 100644
> --- a/variables.c
> +++ b/variables.c
> @@ -3507,7 +3507,11 @@ bind_function_def (const char *name, FUNCTION_DEF 
> *value, int flags)
>if (entry && (flags & 1))
>  {
>dispose_function_def_contents (entry);
> +
> +  cmd = value->command;
> +  value->command = 0;
>entry = copy_function_def_contents (value, entry);
> +  value->command = cmd;
>  }
>else if (entry)
>  return;
> --
> 2.45.0
>

Hello,

I haven't looked at this but it will keep lazy functions safe to
implement right?

Lazy functions are functions that redefine themselves the first time
they are called.  For example they can call a script containing the
proper implementation with heavier code.  Or simplify themselves
depending on the environment or the available tools they detect at
first run.


-- 
konsolebox

Re: [PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

[Chet Ramey]

On 6/1/24 7:15 AM, Koichi Murase wrote:


This patch fixes `bind_function_def' so that it skips the function
body also for the second and later calls.  This reduces the memory
uses of Bash for shell functions by almost half.


Thanks for the analysis and patch. This should not have any negative side
effects, even in pretty-print mode, so we'll try it.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

[Koichi Murase]

To add some contexts not in the commit message, I knew that recent
versions of Bash consume more memory when the same shell script is
loaded.  After bisecting, I realized that the increase in memory use
was actually caused by a single commit ba4ab055 (see the attached
image.  The vertical axis is the increase of RSS measured by comparing
the results of `ps -o rss "$$"' before and after `source 

[PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

[Koichi Murase]

The function `bind_function_def' (variables.c) stores the function
metadata in the hash map `shell_function_defs' in variables.c.  The
saved information is used by BASH_SOURCE (execute_cmd.c) and the
output of `declare -F func' with `shopt -s extdebug'
(builtin/declare.def) through the interface `find_function_def'
(variables.c).  The function body (i.e., funcdef->command) saved in
the hash map is not used anywhere and does not need to be saved in the
hash map.  In fact, the function body is not saved in the first call
of `bind_function_def' for the function name.

The problem is that the function body is saved for the second and
later calls of `bind_function_def' for the same function name.  When a
function is defined, `bind_function_def' is always called twice in its
parsing phase (`make_function_def' in make_cmd.c) and its defining
phase (`execute_intern_function' in execute_cmd.c).  As a result, the
function body is always saved in the hash map `shell_function_defs'
after the second call.  This doubles the memory used for shell
functions because the function bodies are already intended to be saved
in a separate hash map `shell_functions' (variables.c).

This patch fixes `bind_function_def' so that it skips the function
body also for the second and later calls.  This reduces the memory
uses of Bash for shell functions by almost half.

---
 variables.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/variables.c b/variables.c
index 84b30d93..0e785742 100644
--- a/variables.c
+++ b/variables.c
@@ -3507,7 +3507,11 @@ bind_function_def (const char *name, FUNCTION_DEF 
*value, int flags)
   if (entry && (flags & 1))
 {
   dispose_function_def_contents (entry);
+
+  cmd = value->command;
+  value->command = 0;
   entry = copy_function_def_contents (value, entry);
+  value->command = cmd;
 }
   else if (entry)
 return;
-- 
2.45.0

is there no copy of vars declared for every function but one global 'local' only ?

[Alex fxmbsw7 Ratchev]

i have my codes much ready, but now on a clean reboot i noticed it
doesnt do few stuffs anymore
i call a per code that does eval, which i seem to call twice or trice
inside stacked
the content of args=( ) or files=( ) doesnt seem anymore active after some run
could that be ?
i guess the solution is to make a for copy instead of [[ -v args[++i]
but with that how to make it extend-able

for anyone who cares about the code, attached is ogt.tgz
in the code ( ogt/ogt ) there is

. "$_hd"/function/per '. "$_hd"/init/"$per"' \
 set_n_shopt mktermv vars aliases functions keywords traps paths autoloads

till vars it works, or halfways, then aliases and the rest dont get
parsed at all
cause args[++i] or files[++i] is no more


ogt.tgz
Description: application/compressed-tar

Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE

[L A Walsh]

On 2020/12/08 06:07, Chet Ramey wrote:

On 12/7/20 8:02 PM, L A Walsh wrote:

  

The problem is that bash isn't displaying a 'tab' character where
one was typed.  



It's readline and redisplay. Readline expands tabs to spaces using an
internal tab stop of 8. This allows it to be sure of the physical cursor
location, especially when you're doing things like wrapping lines, and
insulates it from varying terminal behavior.
  

*snark* That's nice, why not just display 'X' instead of spaces?  Wouldn't
that also insulate readline from varying terminal behavior? *not really, 
but...*


I'm not sure it is the place of a an in-line-editor to override terminal 
features.


However, as readline is an editor and most editors allow setting the 
tabs (as well as
whether or not to use hard-tabs or expand them).  If readline has to 
"insulate",

just like vi/vim -- have the tabstop and whether to expand be in a startup
file like .inputrc.  Right now, .inputrc has the facility to define how 
characters
are to be interpreted.  Why not put the option to expand w/spaces in 
there, as well
as what a tab character expands (or maps to). 

Bash also overrides existing standards with regards to tabs wrapping.  
It seems that
many or most terminals (xterm compat, linux console-compat, etc) don't 
wrap to the
next line when a tab is pressed. The reasoning for that was that tab was 
supposed to
skip to the next field in the same line.  Wrapping is beyond the scope 
of function

for tabbing.
  

With many (most?) terminal windows these days, especially
Unicode-enabled ones, the terminal has to read what is on the screen to
be able to read the binary code of whatever is displayed on the screen,
Otherwise, it wouldn't be able to read typed unicode.



This is not relevant to the issue.
  
  
   It was meant to illustrate that terminals are using the binary 
representation
of the characters typed -- and that arbitrarily changing the binary 
representation

(like tabs->spaces) will mess up / corrupt the user's output stream.

Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE

[L A Walsh]

On 2020/12/08 06:28, Greg Wooledge wrote:

The end result is that it's basically impossible to preserve the original
whitespace of your source material across a terminal copy/paste operation.
So don't count on that.
  


   If you use a random terminal to copy/paste, sure, but if you use a 
specific

product that maintains fidelity, then it's not true.


   Especially nice are term-progs that automatically reflow text *as 
you resize*
the terminal.  Like if you see 100 characters written to an 80-column 
terminal,

that line wraps the text, when you expand the width, you retain the original
white space.  That's why programs that don't preserve what you wrote are 
annoying.
And note -- you see the reflow in real-time as you change dimensions -- 
not just

at the end.

   Imagine working on a terminal that only displayed upper case even if the
differentiation was saved when stored.  You can't really see the text as 
"it is"

when you enter it or re-edit it.  With it putting in something different on
display than what is really there, you get things like (tab chars between
each letter):
 echo "a b   c   d   e   f   g   h   
i   j   k   l   m   n   o   p   q   
r   s   t   a   b   c   d   e   f   
g   h   i   j   k   l   m   n   o   
p   q   r   s   t"
a b c d e f g h i j k l m n o p q r s t a b c d e f g h i j k l m n o p 
q r s t


If you re-edit a line with tabs in it that displays like it does in the 
bottom

line, above (tabs ever 2 spaces), the re-edited "line" takes up 4 lines.

Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE

[Greg Wooledge]

On Tue, Dec 08, 2020 at 09:07:33AM -0500, Chet Ramey wrote:
> On 12/7/20 8:02 PM, L A Walsh wrote:
> 
> > The problem is that bash isn't displaying a 'tab' character where
> > one was typed.
> 
> It's readline and redisplay. Readline expands tabs to spaces using an
> internal tab stop of 8. This allows it to be sure of the physical cursor
> location, especially when you're doing things like wrapping lines, and
> insulates it from varying terminal behavior.

In addition to what I said earlier, there is a distinction between
things that you *typed* in bash/readline, and then tried to copy with
the mouse, and text that was generated by a command (e.g. cat yourscript),
which you then tried to copy.

And if you're actually typing in a text editor, rather than in bash, then
obviously the behavior of the editor is what matters.

The end result is that it's basically impossible to preserve the original
whitespace of your source material across a terminal copy/paste operation.
So don't count on that.

There's a *reason* bash introduced the $'\t' quoting.  Use it, rather
than using literal tab characters.

Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE

[Chet Ramey]

On 12/7/20 8:02 PM, L A Walsh wrote:


The problem is that bash isn't displaying a 'tab' character where
one was typed.  


It's readline and redisplay. Readline expands tabs to spaces using an
internal tab stop of 8. This allows it to be sure of the physical cursor
location, especially when you're doing things like wrapping lines, and
insulates it from varying terminal behavior.


With many (most?) terminal windows these days, especially
Unicode-enabled ones, the terminal has to read what is on the screen to
be able to read the binary code of whatever is displayed on the screen,
Otherwise, it wouldn't be able to read typed unicode.


This is not relevant to the issue.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE

[felix]

On Tue, Dec 08, 2020 at 08:07:18PM +0700, pepa65 wrote:
> On 08/12/2020 19.55, Greg Wooledge wrote:
> > Some terminals, when fed a tab character, will preserve that knowledge
> > in memory; then, when you copy text from that part of the terminal
> > window using your mouse, the terminal will put a tab byte into the
> > selection/clipboard.
> 
> Interesting! Which terminal does that??

It seem that ``gnome-terminal'' and ``mate-terminal'' do so.

while ``xterm'', ``rxvt'' and ``konsole'' does'nt.

-- 
 Félix Hauri  --  http://www.f-hauri.ch

Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE

[pepa65]

On 08/12/2020 19.55, Greg Wooledge wrote:
> Some terminals, when fed a tab character, will preserve that knowledge
> in memory; then, when you copy text from that part of the terminal
> window using your mouse, the terminal will put a tab byte into the
> selection/clipboard.

Interesting! Which terminal does that??

(Slightly OT?)
Peter

Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE

[Greg Wooledge]

On Mon, Dec 07, 2020 at 05:02:35PM -0800, L A Walsh wrote:
> If I type in ( +  are keypresses)
> 
> if [[ '' == $'\t' ]]; then echo ok; else echo notok; fi 
> 
> bash displays:
> 
> if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi
> ok

Bash doesn't "display" things.  Your terminal displays that.

> if I now copy the 'if' line and paste it
> 
> if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi
> notok

Some terminals, when fed a tab character, will preserve that knowledge
in memory; then, when you copy text from that part of the terminal
window using your mouse, the terminal will put a tab byte into the
selection/clipboard.

Other terminals, when fed a tab character, will just dump out a bunch
of spaces, and will not remember that there was originally a tab character
as part of their input.  Then, if you copy that part of the text, you'll
just get a bunch of spaces instead of the original tab character.

Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE

[Andreas Schwab]

Just use history or fc -l to display the line as is.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE

[Chris Elvidge]

On 08/12/2020 01:02 am, L A Walsh wrote:

If I type in ( +  are keypresses)

if [[ '' == $'\t' ]]; then echo ok; else echo notok; fi 

bash displays:

if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi
ok


if I now copy the 'if' line and paste it

if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi
notok

if I take the same line from an editor like gvim, it works.
If the test line is in a file, and I use 'cat file' and copy/past the
resulting line, it works.

It is only when bash is displaying the line that it doesn't work.

The problem is that bash isn't displaying a 'tab' character where
one was typed.  With many (most?) terminal windows these days, especially
Unicode-enabled ones, the terminal has to read what is on the screen to
be able to read the binary code of whatever is displayed on the screen,
Otherwise, it wouldn't be able to read typed unicode.

Can this be fixed -- maybe with an option in 'shopt', for those who might
be using a non-expanding terminal, but anyone using an xterm/linux 
compatible

terminal should get the expansions from their terminal.
Where this can be even more annoying is if your terminal's response to a 
tab

is different than that used on old-hardware terminals.

Thanks,
-l










Try Ctrl-V before hitting .

--
Chris Elvidge
England

bash doesn't display user-typed characters; can interfere with COPY/PASTE

[L A Walsh]

If I type in ( +  are keypresses)

if [[ '' == $'\t' ]]; then echo ok; else echo notok; fi 

bash displays:

if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi
ok


if I now copy the 'if' line and paste it

if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi
notok

if I take the same line from an editor like gvim, it works.
If the test line is in a file, and I use 'cat file' and copy/past the
resulting line, it works.

It is only when bash is displaying the line that it doesn't work.

The problem is that bash isn't displaying a 'tab' character where
one was typed.  With many (most?) terminal windows these days, especially
Unicode-enabled ones, the terminal has to read what is on the screen to
be able to read the binary code of whatever is displayed on the screen,
Otherwise, it wouldn't be able to read typed unicode.

Can this be fixed -- maybe with an option in 'shopt', for those who might
be using a non-expanding terminal, but anyone using an xterm/linux 
compatible
terminal should get the expansions from their terminal. 


Where this can be even more annoying is if your terminal's response to a tab
is different than that used on old-hardware terminals.

Thanks,
-l

Re: copy

[Dave Finlay]

Does the /data/test directory exist prior to execution?  Otherwise cp is
just copying the result set one at a time to a regular file at /data/test.

You may want to append a forward slash to the directory name, as that will
cause cp to error if the directory doesn't exist instead.  Or chain the
command after mkdir -p /output/dir.  That will error the same if it isn't a
directory, but also create it if it doesn't exist.  Since you are
interested in the files' timestamps, you may way to use --preserve to
preserve them.

So, something like this:

dest_dir='/data/test'; mkdir -p "${dest_dir}" && find . -type f -mtime +10
-name "*.txt" -exec cp --preserve {} "${dest_dir}" \;



Dave Finlay

On Thu, Feb 25, 2016 at 5:41 PM, Val Krem  wrote:

> Hi,
>
> I want to copy files which are older than 10 days  with the extension file
> name txt.
>
>
> I used the following  and it is not doing what supposed to do
>
>
> find . -type f -mtime +10 -name "*.txt" -exec cp {} /data/test \;
>
> can any one help me out?
>
>

Hard-copy terminals

[Ryan Cunningham]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin14.0.0
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='darwin14.0.0' -DCONF_MACHTYPE='x86_64-apple-darwin14.0.0' 
-DCONF_VENDOR='apple' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H -DMACOSX   -I.  -I. -I./include -I./lib -I./lib/intl 
-I/Users/reeves/Downloads/bash-4.3/lib/intl  -g -O2
uname output: Darwin Kimberly-Reevess-MacBook-7.local 14.0.0 Darwin Kernel 
Version 14.0.0: Sat Sep 27 03:58:47 PDT 2014; 
root:xnu-2782.1.97~11/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin14.0.0

Bash Version: 4.3
Patch Level: 30
Release Status: release

Description:
Some features of Bash don't recognize hard-copy terminals.

Repeat-By:
If you're on a hard-copy terminal, and you invoke Bash,
history recall and "readline" support will be invoked anyway
unless the compiler was told for some other reason not to
enable them.

This patch will adjust "configure" so that it disables those
features by default on hard-copy hosts. (Whether to disable
these features is dependent on the host's attributes---not
the guest's attributes, for cross-compiling purposes.)

Fix:
A patch against the Git HEAD is included below.

diff --git a/bash-master/builtins/fc.def b/bash-master/builtins/fc.def
index cf6b72c..801ede9 100644
--- a/bash-master/builtins/fc.def
+++ b/bash-master/builtins/fc.def
@@ -165,6 +165,13 @@ static void fc_addhist __P((char *));
 #else
 #  define POSIX_FC_EDIT_COMMAND "${FCEDIT:-${EDITOR:-ed}}"
 #endif
+/* "vi" is bad for hard-copy terminals. Use "ed" instead if we find that we
+   are running on a hard-copy terminal. */
+#include "strstr.h"
+if (reg_strstr(getenv(TERM), "^tty")) {
+#  define FC_EDIT_COMMAND "ed"
+#  define POSIX_FC_EDIT_COMMAND "${FCEDIT:-ed}"
+}
 
 int
 fc_builtin (list)
diff --git a/bash-master/configure b/bash-master/configure
index 98bf890..47c3e54 100755
--- a/bash-master/configure
+++ b/bash-master/configure
@@ -2970,8 +2970,10 @@ opt_minimal_config=no
 
 opt_job_control=yes
 opt_alias=yes
-opt_readline=yes
-opt_history=yes
+if ! echo "$TERM" | grep "^tty" >/dev/null; then
+opt_readline=yes
+opt_history=yes
+fi
 opt_bang_history=yes
 opt_dirstack=yes
 opt_restricted=yes
diff --git a/bash-master/configure.ac b/bash-master/configure.ac
index 97e8e04..5bb831c 100644
--- a/bash-master/configure.ac
+++ b/bash-master/configure.ac
@@ -161,8 +161,10 @@ opt_minimal_config=no
 
 opt_job_control=yes
 opt_alias=yes
-opt_readline=yes
-opt_history=yes
+if ! echo "$TERM" | grep "^tty" >/dev/null; then
+opt_readline=yes
+opt_history=yes
+fi
 opt_bang_history=yes
 opt_dirstack=yes
 opt_restricted=yes
diff --git a/bash-master/doc/bash.1 b/bash-master/doc/bash.1
index ec41462..df0de0d 100644
--- a/bash-master/doc/bash.1
+++ b/bash-master/doc/bash.1
@@ -7877,8 +7877,10 @@ if
 .B FCEDIT
 is not set.  If neither variable is set,
 .FN vi
-is used.  When editing is complete, the edited commands are
-echoed and executed.
+is used.  (On a hard-copy terminal,
+.FN ed
+is used, regardless.)  When editing is complete, the edited commands
+are echoed and executed.
 .sp 1
 In the second form, \fIcommand\fP is re-executed after each instance
 of \fIpat\fP is replaced by \fIrep\fP.
diff --git a/bash-master/include/strstr.h b/bash-master/include/strstr.h
new file mode 100644
index 000..b3fa0dd
--- /dev/null
+++ b/bash-master/include/strstr.h
@@ -0,0 +1,44 @@
+/* strstr.h -- A regular expression version of strstr(). */
+
+/* Copyright (C) 2011 Andreas W. Wylach, Stack Overflow.
+   Copyright (C) 2014 Free Software Foundation, Inc.
+
+   This file is part of GNU Bash, the Bourne Again SHell.
+
+   Bash is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation, either version 3 of the License, or
+   (at your option) any later version.
+
+   Bash is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with Bash.  If not, see <http://www.gnu.org/licenses/>.
+*/
+
+char * reg_strstr(const char *str, const char *pattern) {
+char *result = NULL;
+regex_t re;
+regmatch_t match[REG_MATCH_SIZE];
+
+if (str == NULL)
+return NULL;
+
+if (regcomp( &re, pattern, REG_ICASE | REG_EXTENDED) != 0) {
+regfree( &

Re: Copy in bash

[Bob Proulx]

vin_eets wrote:
> I am using windows 

Then you will need to be aware of windows specific conventions.

> I wanna copy a file in folder from one location to another folder in another
> drive.
> 
> Its working fine but not when file name contain spaces i.e. if the filename
> is a b c
> 
> What would be script to acheive this functionality

You will need to quote the filename to preserve the spaces.

  $ cp "a b c" /some/other/directory/

Bob

Copy in bash

[vin_eets]

I am using windows 

I wanna copy a file in folder from one location to another folder in another
drive.

Its working fine but not when file name contain spaces i.e. if the filename
is a b c

What would be script to acheive this functionality
-- 
View this message in context: 
http://old.nabble.com/Copy-in-bash-tp31789683p31789683.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.

Re: cp command will copy to subdirectory without appending /

[Marc Herbert]

> The problem is dead-simple. You cannot run this command multiple times:
> 
> cp -R  ./dirfoo  ./dirfoo.backup
> 

Sorry to add yet another (last) off topic message but I must do justice
to GNU cp.  GNU cp actually does support the above thanks to a
(non-standard) option:

 cp -R -T ./dirfoo  ./dirfoo.backup

For details see:  info coreutils "Target Directory"

Re: cp command will copy to subdirectory without appending /

[Marc Herbert]

Bob Proulx a écrit :
> Todd Partridge wrote:
 
> If the target has an appended '/' then the destination must be a directory.

But with cp (GNU coreutils) 6.12, appending '/' to the target does not seem
to make any difference?

 
>> I think the proper behavior here for 'cp -R test2 test' would be to
>> error and print that 'Folder already exists'.
> 
> Of course that would break decades of scripts which expect the
> standard behavior.  I don't understand why would you change this long
> standing useful behavior.  Could you say a few words more about what
> your problem is with the current behavior?

The problem is dead-simple. You cannot run this command multiple times:

cp -R  ./dirfoo  ./dirfoo.backup

That's all.


The usual workaround is to "rm -rf ./dirfoo.backup" systematically. It
is tedious and easy to forget. And it prevents adding any non-dirfoo
content to dirfoo.backup.

cp is too clever. It should not behave in a completely different way
depending on the external environment. It should ideally depend only on
the user input (that is: trailing slash or not). This is
called "Referential transparency"

rsync's opinion on this topic is interesting. The "rm -rf" workaround is
obviously not acceptable for rsync. But rsync did not want to depart
from existing syntax either. So rsync added its own, somewhat funny
workaround: appending a trailing slash to the source directory.

 
>> Appending a / would imply the directory:
>> cp -R test2 test/
>> This usage will remove the ambiguity of the command between the copy
>> function and the rename function.


> Please rephrase your question and send it to bug-coreut...@gnu.org.

This is probably not worth the hassle considering that any change would
break decades of scripts.

Re: cp command will copy to subdirectory without appending /

[Todd Partridge]

On Tue, Oct 20, 2009 at 12:59 AM, Bob Proulx  wrote:
> Todd Partridge wrote:
>> The cp command will copy to a subdirectory without an appending /
>
> You have reached bug-bash, not bug-coreutils.  The 'cp' program is in
> the GNU Coreutils project and so bug reports for 'cp' should go to
> bug-coreut...@gnu.org and not to bug-bash.  The bug-bash list is for
> bugs and discussion about bash.
>
>> mkdir test test2
>> touch abc test
>> touch bcd test2
>
> I think you have typed this in incorrectly.  That produces:
>
>  ./abc
>  ./bcd
>  ./test
>  ./test2

Yes, I did.  The correct syntax, would be:

mkdir test test2
touch abc test/
touch bcd test2/

>
>> cp -R test2 test
>
> Because test is a directory test2 will be copied into that directory.
> With the above that produces:
>
>  ./abc
>  ./bcd
>  ./test
>  ./test/test2
>  ./test2
>
>> ls test
>> test2 abc
>
> That result cannot be produced from the given commands.  Please
> rephrase the question.

? I was tired last night :), the good typing would be:

ls test/
test2  abc

>
>> Since the cp command can also rename
>
> I think you misunderstand how cp works.  A quick and casual summary
> here.  If the target is not a directory then the source file
> (singular) is copied to the destination.  If the target is a directory
> then cp copies the source files (one or more) into the destination
> directory.  If the target has an appended '/' then the destination
> must be a directory.

Because the cp command also renames, I understand the default behavior
to assume that you want to cp.  But I believe the default behavior to
assume a directory 'test/'  when typing 'test' would lead to more
problems for advanced users.  Feedback that 'directory already exists'
I think would be a more direct behavior.  Hmm.

>
> Here is the full standards document:
>
>  http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html
>
>> I think the proper behavior here for 'cp -R test2 test' would be to
>> error and print that 'Folder already exists'.
>
> Of course that would break decades of scripts which expect the
> standard behavior.  I don't understand why would you change this long
> standing useful behavior.  Could you say a few words more about what
> your problem is with the current behavior?

Yeah, well there is little doubt that this would break things :).  For
advanced users I would actually see this as a benefit though we
probably are all responsible for the occasional forgetting of
appending a backslash.

>
>> Appending a / would imply the directory:
>> cp -R test2 test/
>> This usage will remove the ambiguity of the command between the copy
>> function and the rename function.
>
> Please rephrase your question and send it to bug-coreut...@gnu.org.
>
> Thanks
> Bob
>

Appreciate the email bob, will get with bug-coreut...@gnu.org.



-- 
When in trouble or in doubt run in circles, scream and shout. - Robert
A. Heinlein
My Linux Blog - http://linuxtidbits.wordpress.com

Re: cp command will copy to subdirectory without appending /

[Bob Proulx]

Todd Partridge wrote:
> The cp command will copy to a subdirectory without an appending /

You have reached bug-bash, not bug-coreutils.  The 'cp' program is in
the GNU Coreutils project and so bug reports for 'cp' should go to
bug-coreut...@gnu.org and not to bug-bash.  The bug-bash list is for
bugs and discussion about bash.

> mkdir test test2
> touch abc test
> touch bcd test2

I think you have typed this in incorrectly.  That produces:

  ./abc
  ./bcd
  ./test
  ./test2

> cp -R test2 test

Because test is a directory test2 will be copied into that directory.
With the above that produces:

  ./abc
  ./bcd
  ./test
  ./test/test2
  ./test2

> ls test
> test2 abc

That result cannot be produced from the given commands.  Please
rephrase the question.

> Since the cp command can also rename

I think you misunderstand how cp works.  A quick and casual summary
here.  If the target is not a directory then the source file
(singular) is copied to the destination.  If the target is a directory
then cp copies the source files (one or more) into the destination
directory.  If the target has an appended '/' then the destination
must be a directory.

Here is the full standards document:

  http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html

> I think the proper behavior here for 'cp -R test2 test' would be to
> error and print that 'Folder already exists'.

Of course that would break decades of scripts which expect the
standard behavior.  I don't understand why would you change this long
standing useful behavior.  Could you say a few words more about what
your problem is with the current behavior?

> Appending a / would imply the directory:
> cp -R test2 test/
> This usage will remove the ambiguity of the command between the copy
> function and the rename function.

Please rephrase your question and send it to bug-coreut...@gnu.org.

Thanks
Bob

cp command will copy to subdirectory without appending /

[Todd Partridge]

The cp command will copy to a subdirectory without an appending /

mkdir test test2
touch abc test
touch bcd test2
cp -R test2 test
ls test
test2 abc

Since the cp command can also rename I think the proper behavior here
for 'cp -R test2 test' would be to error and print that 'Folder
already exists'.  Appending a / would imply the directory:

cp -R test2 test/

This usage will remove the ambiguity of the command between the copy
function and the rename function.

-- 
When in trouble or in doubt run in circles, scream and shout. - Robert
A. Heinlein
My Linux Blog - http://linuxtidbits.wordpress.com