Crontab accepts files with no newline before EOL/EOF. Cron ignores file

Additional information.

setting EDITOR=/usr/bin/vi and exporting

then running crontab -e will allow you to create a usable cron file

I have verified the above and agree this has affected me from using cron. This is a bug.
Also eol should be eof in the title of the bug.

Setting the EDITOR to something that will solve the problem is a workaround. It's helpful, but really it's just a band-aid; cron needs to be fixed. If it weren't written in C I would submit the patch myself. There is no reason to silently ignore user input. Adding a newline silently would save a lot of frustration, and nobody is relying on the current behaviour.

BTW, in Emacs just add this to your .emacs file: (setq require-final-newline t)

I have created a patch for crontab.c which adds a warning if there is no newline at the end of the file. I have followed the original author's example of generating a diagnostic if any file function breaks.

Please consider integrating upstream.

Perhaps this version would be better. Adds extra lines to make warning clearer.

Here is an debdiff with the Patch from Nick Hill (the second one)

Nick, I don't think this makes sense. Why add a warning when crontab could just silently add the newline (assuming the text it's given has non-zero length), as a previous commenter suggested? It's always better to silently do the right thing, if possible, than to issue a warning.

(Also, please always use 'diff -u' rather than plain diff; plain diff's output is not suitable for source code changes as it breaks as soon as the code it might be applied to changes.)

Hello Colin

Being new to general-release code modifications, I suppose I have a starting point of taking a minimally-invasive approach; to take an approach least likely to introduce bugs. Eg if ported to Windows or OSX with different EOL conventions. \r \r\n

That isn't to say I have any reason to believe the solution you and technomancy mentioned will introduce any bugs in Ubuntu, so I guess a consensus is growing around file modification. I'll take a look at that.

Unsubscribing main sponsors team for now. Please resubscribe once there is a patch to upload. Thanks for your work on this!

Nick Hill, are you still working on this? Thanks!

This bug was fixed in the package cron - 3.0pl1-113ubuntu1

---------------
cron (3.0pl1-113ubuntu1) maverick; urgency=low

  * Merge from debian unstable. Fixes:
    - LP: #46493 (this should have been fixed way back in 3.0pl1-87, and I
      confirmed it is no longer a problem)
    - LP: #118168 (Debian #79037)
    - LP: #151231 (Debian #155109, #443615)
    - LP: #308341 (Debian #437180)
  * Remaining changes:
    - debian/control:
      + Build-Depends on debhelper >= 7.3.15ubuntu2, for Upstart
      + Drop MTA and lockfile-args to Suggests
    - add debian/cron.upstart
    - debian/postinst: remove calls to update-rc.d, invoke-rc.d and
      /etc/init.d/cron
    - debian/postrm: remove call to update-rc.d
    - debian/prerm: remove calls to invoke-rc.d and /etc/init.d/cron
    - debian/rules: install Upstart job
  * Drop the following changes, now in debian:
    - popen.c: check return code of initgroups() in cron_popen()
    - debian/control: add missing ${misc:Depends}
    - debian/control: Depends bump on lsb to >= 3.2.12ubuntu2. No longer
      required now that we use Upstart
    - debian/cron.pam: switch from including common-session to including
      the new common-session-noninteractive
    - pathnames.h: use sensible-editor

cron (3.0pl1-113) unstable; urgency=medium

  [ Christian Kastner / Javier Fernandez-Sanguino ]
  * debian/postinst:
    - Now that permissions and ownership of crontabs are changed unconditionally,
      do not attempt to chown user crontabs if none are present. Closes: #585636
    - Only change permissions if the crontabs directory exist

cron (3.0pl1-112) unstable; urgency=low

  [ Christian Kastner ]
  * do_command.c:
    - Don't send mail when a job exits non-zero, only send mail if the job sent
      output to stderr. This behaviour was introduced erroneously; while it
      does have merit, it is completly against standard cron behaviour.
      Closes: #581612
  * debian/compat:
    - Bumped debhelper compatibility to 7
  * debian/control:
    - Bumped Standards-Version to 3.8.4 (no change needed)
    - Build-Depend on debhelper (>= 7.0.50~)
    - Added dependency on ${misc:Depends} to package cron
  * debian/cron.init:
    - Changed Default-Stop from (1) to (empty). rc0 and rc6 were removed in
      3.0pl1-101 because the stop action -- sending SIGTERM/SIGKILL to cron
      on shutdown/reboot -- was redundant. This, however, also applies to
      rc1, because killprocs will do that for us.
  * debian/postinst:
    - Removed obsolete dpkg file backup code, this has been handed over to dpkg
      in 3.0pl1-109
    - Removed last remaining stop action (for rc1) from upate-rc.d (see above)
    - Add dpkg-statoverride for /usr/bin/crontab, and unconditionally change
      permissions of /var/spool/cron/crontabs. Closes: #304036, #460095
  * debian/standard.monthly:
    - Removed because it had been empty for years and therefore served no
      purpose
  * debian/cron.bug-{control,script}
    - Added to extend information submitted by reportbug
  * debian/rules:
    - Applied changes for standard.monthly and cron.bug-{control,script} above
  * debian/copyright:
    - Updated to reflect recent contribution...