]> git.donarmstrong.com Git - perltidy.git/commitdiff
cleanups before release
authorSteve Hancock <perltidy@users.sourceforge.net>
Thu, 30 May 2019 22:47:16 +0000 (15:47 -0700)
committerSteve Hancock <perltidy@users.sourceforge.net>
Thu, 30 May 2019 22:47:16 +0000 (15:47 -0700)
CHANGES.md
lib/Perl/Tidy.pm

index e81e4d2c6c3aef65d356ce623ab666cb70aa739b..54f577f8b020be46919cb660c18ca189c298a612 100644 (file)
@@ -12,7 +12,7 @@
 
     - Merged patch to fix Windows EOL translation error with UTF-8 written by
       Ron Ivy. This update prevents automatic conversion to 'DOS' CRLF line
-      endings.
+      endings.  Also, Windows system testing at the appveyor site is working again.
 
     - RT #128280, added flag --one-line-block-semicolons=n (-olbs=n) 
       to control semicolons in one-line blocks.  The values of n are:
index bc2c1a128d534dafebc1631777215edab7dfbb7e..69f7f8c5df34098800840a973a761234bff30890 100644 (file)
@@ -1350,18 +1350,20 @@ EOM
                         }
                     }
 
-                    # Make the output file writable unless we are in -b mode.
-                    # The reason is that perltidy does not unlink existing
-                    # output files before writing to them, for safety, so if an
-                    # existing output file is marked not writable then perltidy
-                    # will stop. This can prevent a disaster for a user who
-                    # accidentally enters "-o important_data", but it also
-                    # means that perltidy may fail when rerun with its default
-                    # output file unless it marks its own output files
-                    # writable. The alternative, of always unlinking the
-                    # designated output file, is unsafe, except in -b mode,
-                    # where there is an assumption that a previous backup can
-                    # be unlinked even if not writable.
+                   # Make the output file for read + write unless we are in -b mode.
+                   # Explanation: perltidy does not unlink existing output
+                   # files before writing to them, for safety.  If a designated
+                   # output file exists and is not writable, perltidy will halt.
+                    # This can prevent a data loss if a user 
+                   # accidentally enters "perltidy infile -o
+                   # important_ro_file", or "perltidy infile -st
+                   # >important_ro_file". But it also means that perltidy can
+                   # get locked out of rerunning unless it marks its own
+                   # output files writable. The alternative, of always
+                   # unlinking the designated output
+                   # file, is less safe and not always possible, except in -b
+                   # mode, where there is an assumption that a previous backup
+                   # can be unlinked even if not writable.
                     if ( !$in_place_modify ) {
                         $output_file_permissions |= oct(600);
                     }