Bug 988152 - /etc/profile.d/colorls.sh leaves .colorlsXXX files in /tmp
Summary: /etc/profile.d/colorls.sh leaves .colorlsXXX files in /tmp
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils   
(Show other bugs)
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ondrej Oprala
QA Contact: Fedora Extras Quality Assurance
: 994722 1055086 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-24 21:20 UTC by Henrique Martins
Modified: 2014-02-05 03:33 UTC (History)
11 users (show)

Fixed In Version: coreutils-8.21-13.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-02-05 03:33:55 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Henrique Martins 2013-07-24 21:20:08 UTC
Description of problem:
My /tmp now has a few .colorlsXXX files.  This is new with F19

Version-Release number of selected component (if applicable):

How reproducible:
Not sure.

Steps to Reproduce:
1. Normal use, probably requires ssh/scp, starting shells, etc.

Actual results:
several.colorlsXXX files in /tmp

Expected results:
No junk left behind

Additional info:
colorls.sh (and maybe .csh, didn't look) uses mktemp to create a temporary file in /tmp.  It does a rm -f on the file before it exits, but not before three possible returns paths, which, to be followed, will leave the file behind.

Comment 1 Ondrej Vasik 2013-07-25 06:17:14 UTC
Thanks for report, as /tmp is now tmpfs and files are not that big, it shouldn't be a big issue. Worth to fix anyway. Reassigning to Ondrej O., who is the author of the include patch.

Comment 2 Henrique Martins 2013-07-25 13:57:24 UTC
/tmp is NOT on /tmpfs in any of my systems (let's not get into that argument here).  I also don't reap files on /tmp, thus they will stay.

I moved a few lines around on both scripts and that may fix the problem in almost all cases (may need to rm the file on a trap to do it better). I'll post my changes if it seems to work and I don't see a patch here before.

Comment 3 Ondrej Oprala 2013-08-14 12:34:04 UTC
*** Bug 994722 has been marked as a duplicate of this bug. ***

Comment 4 Ondrej Oprala 2013-08-14 14:14:10 UTC
Should be fixed in coreutils-8.21-12.fc19

Comment 5 Trevor Cordes 2013-08-19 00:14:11 UTC
I just noticed this bug because a user who never logs in had a zillion .colorls files in /tmp.  It turns out that user has some procmail rules setup to run every time an email comes in, and each email time coincided with the .colorls file.

(User's shell is tcsh and sources the .csh's.)

Anyhow, even if comment #4 has this bug fixed, should this (and other scripts) NOT be running on non-interactive sessions?  The script seems to look at $TERM but not in such a way that it instantly aborts when it detects a non-interactive shell.  Can't all these scripts abort when non-interactive to not waste time?  For my purposes, I think most of the scripts are useless and I'd like a way to rm or disable many of them (like colorls), but yum will put them back in everytime coreutils updates.

Comment 6 Ondrej Oprala 2013-08-19 11:34:15 UTC
Well, Scott's problem in the duplicate bug was that he set $PS1 even for non-interactive shells, which bypassed the simple way these scripts check for them (return if $PS1 not set). Maybe there's a similar issue with the user you mentioned.

Comment 7 Scott Baker 2013-08-19 14:57:40 UTC
I got on #bash and asked for the best way to test for an interactive shell and the answer was:

if [[ -t 0 ]]

Not to check for $PS1. I modified my script to do that and I haven't had the problem since. Perhaps the lscolors things should test that way also? Here is the documentation for this feature:


Comment 8 Trevor Cordes 2013-08-19 15:27:36 UTC
Comment #6: ah, yes I see the $PS1 check in the .sh, but the equivalent check is not in the .csh (for colorls, not sure about the other scripts).

The .csh's should have the equivalent check for non-int.  The checks I use personally are along the lines of:

if (! $?prompt) goto _end

I can't see any equivalent to -t in [t]csh as per comment #7.

Putting a similar check/goto in the .csh's should suffice.

Comment 9 Trevor Cordes 2013-11-13 09:38:10 UTC
If I modify these .csh files to effect my fix in comment #8 can I put the patches here to have them incorporated?  Does the $?prompt test sound like a good one to rely on?

I also had a different idea that might make maintenance easier to avoid this problem in the future: what if the csh scripts call bash to run the bash scripts and somehow capture the changes they make to bash, and convert that to take effect in csh/tcsh.  By that I mean do something like call a wrapper script that saves the state (vars/envvars) of a new bash process, run the .sh version file, look at the state (vars/envvars) after the run, and spit out csh commands that would effect the same thing in csh/tcsh.  Then we could eval that output in csh/tcsh.

Yes, that is terribly inefficient, but perhaps ultimately the better way as the scripts are tiny and few.  Maintenance of the "csh version" of these files would then be "for free" essentially.

Either way, something should be done because the .csh files are currently *majorly broken* in the sense that they do not do the same thing as their .sh counterparts.

Comment 10 Ondrej Vasik 2013-11-13 13:30:27 UTC
[[ -t 0 ]] seems like a bashism - we use .sh scripts on ksh, which limits us in many ways. Still definitely worth to improve.

I agree with the statement .csh files are broken and they should do the same thing as the .sh counterpart - if you have any patch/proposal, feel free to post it here, we can incorporate it into rawhide (and later released fedoras) version of coreutils. Check from comment #8 might be ok - do you have some more ideas what to fix the "*majorly broken*" csh path? I don't think that the "bash solution" is the right way.

Comment 11 Trevor Cordes 2013-12-22 14:50:53 UTC
Very strange, the attachment part of bugzilla isn't working for me (I hit submit but nothing happens).  The patches are so short, I will put them here:

Add interactive shell test at top and completely skip (exit) out of the file if we're not interactive.  Don't even set aliases, as they are useless in a non-int shell.  Exit (as opposed to sh's return) works fine here, as exiting a "source" command just returns from the "source" and doesn't quit the original shell.

For people like me who don't want color stuff set at all, even on interactive, the current code allows one to set USER_LS_COLORS=1 in the calling file (usually /etc/csh.cshrc) beforehand.

patch for /etc/profile.d/colorls.csh to skip on non-int shells and fix this bug

--- coreutils-colorls.csh	2013-05-08 02:40:49.000000000 -0500
+++ coreutils-colorls.csh.new	2013-12-22 08:19:33.051771231 -0600
@@ -1,3 +1,6 @@
+# skip everything for non-interactive shells
+if (! $?prompt) exit
 # color-ls initialization
 if ( $?USER_LS_COLORS ) then
   if ( "$USER_LS_COLORS" != "" ) then

Also, I've tweaked the bash version as it's also a bit buggy/suboptimal:

--- coreutils-colorls.sh	2013-05-08 02:40:49.000000000 -0500
+++ coreutils-colorls.sh.new	2013-12-22 08:31:07.200811536 -0600
@@ -1,15 +1,14 @@
 # color-ls initialization
+# Skip all for noninteractive shells.
+[ -z "$PS1" ] && return
 #when USER_LS_COLORS defined do not override user LS_COLORS, but use them.
 if [ -z "$USER_LS_COLORS" ]; then
   alias ll='ls -l' 2>/dev/null
   alias l.='ls -d .*' 2>/dev/null
-  # Skip the rest for noninteractive shells.
-  [ -z "$PS1" ] && return
   TMP="`mktemp .colorlsXXX --tmpdir=/tmp`"

There is no point in running any of the file if it's non-interactive (in either shell) as non-ints don't need aliases and certainly don't need ls coloring.

Comment 12 Trevor Cordes 2013-12-22 14:57:21 UTC
Also, on my system there are many other .csh files that could use the same treatment.  Some do only setenv, which is legit for non-int shells, so those can be left alone.  I identified these as also setting aliases and other int-only things:



Obviously different people will have different rpm's installed that create different .csh files.  An exhaustive scan and fix-up of all of them would be tricky.

For sure, colorls is the most egregious one, creating temp files/dirs.

Comment 13 Trevor Cordes 2013-12-22 15:02:03 UTC
Sorry, I forgot to fix the actual bug in cases where people use the default settings!  Below will fix the leftover temp stuff as it rm's at every exit point now.

--- coreutils-colorls.csh	2013-05-08 02:40:49.000000000 -0500
+++ coreutils-colorls.csh.new	2013-12-22 08:59:34.622138773 -0600
@@ -1,3 +1,6 @@
+# skip everything for non-interactive shells
+if (! $?prompt) exit
 # color-ls initialization
 if ( $?USER_LS_COLORS ) then
   if ( "$USER_LS_COLORS" != "" ) then
@@ -30,18 +33,25 @@
 set INCLUDE="`cat "$COLORS" | grep '^INCLUDE' | cut -d ' ' -f2-`"
-if ( ! -e "$COLORS" ) exit
+if ( ! -e "$COLORS" ) then
+  rm -f $TMP
+  exit
 if ( "$INCLUDE" != '' ) cat "$INCLUDE" > $TMP
 cat "$COLORS" | grep -v '^INCLUDE' >> $TMP
 eval "`dircolors -c $TMP`"
-if ( "$LS_COLORS" == '' ) exit
+if ( "$LS_COLORS" == '' ) then
+  rm -f $TMP
+  exit
 set color_none=`sed -n '/^COLOR.*none/Ip' < $COLORS`
 if ( "$color_none" != '' ) then
-   unset color_none
-   exit
+  unset color_none
+  rm -f $TMP
+  exit
 unset color_none
 rm -f $TMP

Comment 14 Trevor Cordes 2013-12-22 15:15:30 UTC
Also, the proper fix (ignore the one in comment #11) for bash .sh that takes care of cleaning up temp files:

--- coreutils-colorls.sh	2013-05-08 02:40:49.000000000 -0500
+++ coreutils-colorls.sh.new	2013-12-22 09:13:46.964471296 -0600
@@ -1,15 +1,14 @@
 # color-ls initialization
+# Skip all for noninteractive shells.
+[ -z "$PS1" ] && return
 #when USER_LS_COLORS defined do not override user LS_COLORS, but use them.
 if [ -z "$USER_LS_COLORS" ]; then
   alias ll='ls -l' 2>/dev/null
   alias l.='ls -d .*' 2>/dev/null
-  # Skip the rest for noninteractive shells.
-  [ -z "$PS1" ] && return
   TMP="`mktemp .colorlsXXX --tmpdir=/tmp`"
@@ -32,14 +31,23 @@
   # Existence of $COLORS already checked above.
-  [ -n "$COLORS" ] || return
+  if [ ! -n "$COLORS" ]; then
+    rm -f $TMP
+    return
+  fi
   [ -e "$INCLUDE" ] && cat "$INCLUDE" > $TMP
   cat "$COLORS" | grep -v '^INCLUDE' >> $TMP
   eval "`dircolors --sh $TMP 2>/dev/null`"
-  [ -z "$LS_COLORS" ] && return
-  grep -qi "^COLOR.*none" $COLORS >/dev/null 2>/dev/null && return
+  if [ -z "$LS_COLORS" ]; then
+    rm -f $TMP
+    return
+  fi
+  if grep -qi "^COLOR.*none" $COLORS >/dev/null 2>/dev/null; then
+    rm -f $TMP
+    return
+  fi
   rm -f $TMP

Comment 15 Trevor Cordes 2013-12-22 15:20:15 UTC
(In reply to Ondrej Vasik from comment #10)
> have some more ideas what to fix the "*majorly broken*" csh path? I don't
> think that the "bash solution" is the right way.

As for broken csh path, I suppose I could look into it, but it should be a new bug, no?  Someone should make it and put a link here.

Personally, I clobber the system's csh path setting with my own sane setting, so I am not impacted by this bug.  Yes, it would be nice if the system "did the right thing" for all csh/tcsh users!

Comment 16 Ondrej Vasik 2013-12-23 09:55:45 UTC
Thanks for the patches, you are right the scripts should do the cleanup even for these cases of exits. With the tmpfs on /tmp it is not so scary, but still having file for each session until reboot is not nice. In addition, I will use only the "no aliases for noninteractive" part of your patches - I believe that the other chunk was fixed by http://pkgs.fedoraproject.org/cgit/coreutils.git/commit/coreutils-colorls.csh?id=f0b6f85aff0496c51c8fcb58197a8a132949a4e5 and http://pkgs.fedoraproject.org/cgit/coreutils.git/commit/coreutils-colorls.sh?id=f0b6f85aff0496c51c8fcb58197a8a132949a4e5 ... they already do the cleanup before any of exits (I'd suggest to use the rawhide version as a base, as there were other minor changes meanwhile).

Feel free to file a new bugzilla for other ".csh" tunings/fixes, if you want to.

Comment 17 Ondrej Vasik 2014-01-20 10:04:41 UTC
*** Bug 1055086 has been marked as a duplicate of this bug. ***

Comment 18 Fedora Update System 2014-01-20 10:42:55 UTC
coreutils-8.21-13.fc19 has been submitted as an update for Fedora 19.

Comment 19 Fedora Update System 2014-01-21 05:53:21 UTC
Package coreutils-8.21-13.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing coreutils-8.21-13.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2014-02-05 03:33:55 UTC
coreutils-8.21-13.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.