Completed odds and ends.

Fork: 0

tundra / tren

Browse code Completed odds and ends. master
1 parent 5d4fd6d commit 474f088e6136e78ca30a71b8e9603d23a8354f85 tundra authored on 7 Apr 2010

Patch

Unified Split

Showing 1 changed file

                Ignore Space
               Show notes
              View
            
          
          69 ■■■■■
          tren.rst
 - Replacing Or Removing All Instances Of A String
 
- Changing A File's "Extension" Suffix
 
- Replace Spaces In A Filename With Underbars
 
- Appending- Or Prepending Strings To An Existing File Name
 
- Ordering File Names By Last Modification Time
 
- Ordering File Names By Modification Time Within Date
 
- Ordering File Names By Size
 
- Undoing A Previous Renaming
 
 
 
ODDS AND ENDS
-------------
 
- Quoting your command line arguments properly for the shell you
  use is critical.  Things like spaces,  ``\``, 
- Quoting your command line arguments properly for the shell you use
  is critical.  Things like spaces, ``\``, and ``-`` have to be
  properly quoted or either the shell or **tren** itself are going to
  complain.  Similarly, when using the ``/$ENV/`` and ``/`cmd`/``
  renaming tokens, make sure to enclose them in single quotes if
  you're using a standard Unix shell like ``bash``.
 
- Whitespace is almost always significant *within* a **tren** option.
  You'll need to put proper quoting around it to perserve if for
  **tren** to see, whether in a renaming request, an alphabet
  definition, or some part of a sequence renaming token.
 
- **tren** will attempt to do any requested renaming.  However,
  if you manage to embed some character in the new name that
  the operating system doesn't like, the renaming will fail and
  you'll be notified of the fact.  Notwithstanding the fact that
  you can do all manner of clever things with **tren**, some
  restraint is called for when constructing new file- or directory
  names.
 
- **tren** will prevent you from trying to rename something to a null
  string or a name too long for the operating system.  Mostly this is
  not an issue *unless* you managed to concoct a renaming request that
  ends up requiring recursive backups.  In that case, the backup
  suffix can be tacked onto the file name enough times that the file
  name becomes too long for the OS to catch.  While **tren** can, and
  does catch this, **it cannot unwind what it has done thus far and
  you CAN LOSE FILES THIS WAY!!!**.  The smart move here is to use
  test mode and make sure your proposed renaming isn't going to
  require deeply recursive backups.
 
 
BUGS, MISFEATURES, OTHER
------------------------
 
-----------------------------
 
::
 
  $Id: tren.rst,v 1.178 2010/04/07 21:04:11 tundra Exp $
  $Id: tren.rst,v 1.179 2010/04/07 21:16:51 tundra Exp $
 
You can find the latest version of this program at:
 
  http://www.tundraware.com/Software/tren
 - Replacing Or Removing All Instances Of A String
 - Changing A File's "Extension" Suffix
+- Replace Spaces In A Filename With Underbars
 - Appending- Or Prepending Strings To An Existing File Name
 - Ordering File Names By Last Modification Time
 - Ordering File Names By Modification Time Within Date
 - Ordering File Names By Size
+- Undoing A Previous Renaming
 ODDS AND ENDS
 -------------
+- Quoting your command line arguments properly for the shell you
+  use is critical.  Things like spaces,  ``\``,
+- Quoting your command line arguments properly for the shell you use
+  is critical.  Things like spaces, ``\``, and ``-`` have to be
+  properly quoted or either the shell or **tren** itself are going to
+  complain.  Similarly, when using the ``/$ENV/`` and ``/`cmd`/``
+  renaming tokens, make sure to enclose them in single quotes if
+  you're using a standard Unix shell like ``bash``.
+- Whitespace is almost always significant *within* a **tren** option.
+  You'll need to put proper quoting around it to perserve if for
+  **tren** to see, whether in a renaming request, an alphabet
+  definition, or some part of a sequence renaming token.
+- **tren** will attempt to do any requested renaming.  However,
+  if you manage to embed some character in the new name that
+  the operating system doesn't like, the renaming will fail and
+  you'll be notified of the fact.  Notwithstanding the fact that
+  you can do all manner of clever things with **tren**, some
+  restraint is called for when constructing new file- or directory
+  names.
+- **tren** will prevent you from trying to rename something to a null
+  string or a name too long for the operating system.  Mostly this is
+  not an issue *unless* you managed to concoct a renaming request that
+  ends up requiring recursive backups.  In that case, the backup
+  suffix can be tacked onto the file name enough times that the file
+  name becomes too long for the OS to catch.  While **tren** can, and
+  does catch this, **it cannot unwind what it has done thus far and
+  you CAN LOSE FILES THIS WAY!!!**.  The smart move here is to use
+  test mode and make sure your proposed renaming isn't going to
+  require deeply recursive backups.
 BUGS, MISFEATURES, OTHER
 ------------------------
 -----------------------------
 ::
+  $Id: tren.rst,v 1.178 2010/04/07 21:04:11 tundra Exp $
+  $Id: tren.rst,v 1.179 2010/04/07 21:16:51 tundra Exp $
 You can find the latest version of this program at:
   http://www.tundraware.com/Software/tren

Show line notes below