1. 14 Oct, 2017 5 commits
    • top: stop neglecting potential utf8 field descriptions · 4e2a1ba9
      And I thought those strange characters I saw with only
      certain translations in Fields Management descriptions
      were resulting from my terminal emulator deficiencies.
      
      Turns out that ol' top wasn't addressing possibilities
      of such descriptions ending with multi-byte sequences.
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: eliminate that potential vulnerability for TOCTOU · 1ba0e999
      Initially, I was going to ignore that coverity warning
      CID #177876. But, since top may be running SETUID it's
      best if it can be avoided instead. The fix was simple.
      
      We'll trade the access() call for a real fopen() call.
      This time-of-check-time-of-use warning should go away.
      ------------------------------------------------------
      
      When XDG support was originally introduced in top, the
      author made a poor choice in access(). A real question
      that needed asking was 'does the file exist'. However,
      the question that was asked was 'can this real user ID
      or this real group ID access the file'. Then, when the
      fopen() is finally issued, top would use the effective
      user ID or the effective group ID to access that file.
      
      That's what opened the potential TOCTOU vulnerability,
      which was important only if top was running SUID/SGID.
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: make 'utf8_justify' independent of non-utf8 logic · 0f5d5031
      By eliminating the call to 'fmtmk', the 'utf8_justify'
      function could more easily be used in libproc someday.
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: utf8 utils should observe indentation conventions · ac76afee
      Gosh, all this time we used indents of 4 spaces, not 3
      spaces which were always the top standard indentation.
      
      [ and we made our 'utf8_embody' a little more robust ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: ensure bug report suggestion agrees with man page · fba7a919
      The top man page was changed back on 10/20/15, in that
      commit shown below. There, freelists.org was suggested
      as the bug reports recipient. But, the program was not
      changed from the original Debian bug reports approach.
      
      Reference(s):
      commit b1f7b2a5
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  2. 06 Oct, 2017 4 commits
  3. 02 Oct, 2017 3 commits
    • top: correct an insidious occasional truncation buglet · f6ee2c00
      With the help of our Swedish translator, hopefully the
      final buglet has now been vanquished in the multi-byte
      translation support. This one was a real nasty bugger.
      
      Although it didn't occur with every terminal emulator,
      occasionally random text lines were being chopped off.
      
      As it turns out, those terminals were blameless. There
      were two separate places in top's show_special routine
      where potential multi-byte sequences were inadequately
      addressed. Solution: exploit existing utf-8 functions.
      
      [ it also became apparent that the translation hints ]
      [ in the top_nls module were deficient. so a special ]
      [ caution was added regarding the final line of txt. ]
      
      Reference(s):
      #68
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: plug a small potential hole in multi-byte support · d5a9965c
      Unlike the insp_mkrow_raw function the insp_mkrow_utf8
      routine is not equipped to print non-ctl, non-printing
      characters like '<7f>'. However, technically that very
      value currently slips through the cracks. So with this
      patch top will now print a space in the unlikely event
      a character with the value of 127 is ever encountered.
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • ps: don't use '+' truncation indicator with multi-byte · 62367def
      The ps program generally supports multi-byte sequences
      in strings representing user and group names. However,
      should a multi-byte sequence span the maximum width of
      a column, the '+' inserted by ps to signify truncation
      will corrupt that sequence, misaligning the text line.
      
      Unfortunately, there's insufficient info returned from
      the escape_str function (who calls escape_str_utf8) to
      provide a robust response. So, this commit will revert
      to the old standby of displaying a number when the '+'
      character would've corrupted that multi-byte sequence.
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  4. 01 Oct, 2017 6 commits
    • top: extend utf-8 multi-byte support to users & groups · cd88d453
      Since all the necessary utf-8 plumbing is now in place
      this commit will extend multi-byte support to user and
      group names. Now top will be on a par with the ps guy.
      
      [ plus, it's also my way of showing appreciation for ]
      [ all those investments silently made by translators ]
      
      Reference(s):
      #68
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: some minor tweaks to the utf-8 multi-byte support · d002bdc4
      Translatable column headers are supposed to be limited
      to no more than 7 characters, even though some columns
      are wider than that or even variable width. That value
      of 7 is dictated by the Fields Management screen which
      will otherwise truncate a column header longer than 7.
      
      Our new utf-8 support did not adequately deal with the
      potential need for truncation of column headers should
      that limit of 7 be exceeded. This patch corrects that.
      
      [ a few comments were also tweaked just a little bit ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • NEWS: acknowledged top's multi-byte support extensions · 0902221b
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: extend multi-byte support to 'Inspection' feature · fad0c620
      The previous commit implemented multi-byte support for
      the basic top user interaction and display provisions.
      This commit completes multi-byte support by addressing
      that 'Inspect Other Output' feature (the 'Y' command).
      
      Few people probably exploit this very powerful feature
      which allows the perusing of any file or piped output.
      And even if nobody uses 'Y', someone will stumble over
      it on the help screen and try it out. Assuming top was
      not built with INSP_OFFDEMO defined, they'll end up on
      the screen our translators have faithfully translated.
      
      Without this patch, such a screen would display with a
      bunch of 'unprintable' characters which will then show
      in the standard (less-like) way as: '^A', '<C3>', etc.
      In other words, those poor screens will be a big mess!
      
      [ this program can even display an executable binary ]
      [ while at that same time supporting Find/Find Next. ]
      [ imagine, a file with no guarantee of real strings! ]
      [ just try a Find using less with such binary files. ]
      
      With this commit, the translated 'Y' demo screens will
      now be properly shown, providing no invalid multi-byte
      characters have been detected. Should that be the case
      then they'll be displayed in that less-like way above.
      
      And, if users go on to fully exploit this 'Y' command,
      there is a good chance that a file or pipe might yield
      output in a utf-8 multi-byte form. Should that be true
      such output will thus be handled appropriately by top.
      
      [ in many respects, this change was more challenging ]
      [ than the basic support within the previous commit. ]
      [ story of my life: least used = most effort needed. ]
      
      Many thanks to our procps-ng translators which enabled
      a proper test of these changed 'Y' command provisions:
      . Vietnamese: Trần Ngọc Quân
      . Polish: Jakub Bogusz
      . German: Mario Blättermann
      . French: Frédéric Marchal, Stéphane Aulery
      
      [ and my sincerest apologies too, for my negligence! ]
      
      Reference(s):
      #68
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: refactored for correct multi-byte string handling · 7ef38420
      When this project first began implementing translation
      support nearly 6 years ago, we overcame many 'gettext'
      obstacles and limitations.  And, of course, there were
      not any actual translations at the time so our testing
      was quite limited plus, in many cases, only simulated.
      
      None of that, however, can justify or excuse the total
      lack of attention to top's approach to NLS, especially
      since some actual translations have existed for years.
      
      When the issue referenced below was raised, I suffered
      immediate feelings of anxiety, doubt and pending doom.
      This was mostly because top strives to avoid line wrap
      at all costs and that did not bode well for multi-byte
      translated strings, using several bytes per character.
      
      I was also concerned over possible performance impact,
      assuming it was even possible to properly handle utf8.
      
      But, after wrestling with the problem for several days
      those initial feelings have now been replaced by guilt
      over any trouble I initially caused those translators.
      
      One can only imagine how frustrating it must have been
      after the translation effort to then see top display a
      misaligned column header and fields management page or
      truncated screens like those of help or color mapping.
      ------------------------------------------------------
      
      Ok, with that off my chest let's review these changes,
      now that top properly handles UTF8 multi-byte strings.
      
      . Performance - virtually all of this newly added cost
      for multi-byte support is incurred during interactions
      with the user. So, performance is not really an issue.
      
      The one occasion when performance is impacted is found
      during 'summary_show()' processing, due to an addition
      of one new call to 'utf8_delta()' in 'show_special()'.
      
      . Extra Wide Characters - I have not yet and may never
      figure out a way to support languages like zh_CN where
      the characters can be wider than most other languages.
      
      . Translated User Name - at some future point we could
      implement translation of user names. But as the author
      of the issue acknowledged such names are non-standard.
      Thus task display still incurs no new multi-byte costs
      beyond those already incurred in that escape.c module.
      
      For raising the issue I extend my sincerest thanks to:
      Göran Uddeborg
      
      Reference(s):
      #68
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: correct a minor instance of wrong NLS macro usage · 01fb8d5a
      The 'N_fmt' and 'N_txt' macros are interchangeable and
      just highlight the 2 str types found in Norm_nlstable.
      
      The change in this patch (strictly cosmetic) was found
      during the coding for what will be the next 2 commits.
      It has not been squashed into either of those so as to
      not muddy up the waters for what was a major refactor.
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  5. 24 Sep, 2017 2 commits
  6. 23 Sep, 2017 3 commits
  7. 03 Sep, 2017 1 commit
  8. 30 Aug, 2017 3 commits
  9. 19 Aug, 2017 3 commits
    • top: protect against the anomalous 'Mem' graph display · a2ceb95e
      Until this patch, top falsely assumed that there would
      always be some (small) amount of physical memory after
      subtracting 'used' and 'available' from the total. But
      as the issue referenced below attests, a sum of 'used'
      and 'available' might exceed that total memory amount.
      
      I'm not sure if this is a problem with our calculation
      of the 'used' amount, a flaw in the kernel 'available'
      algorithms or some other reason I cannot even imagine.
      
      Anyway, this patch protects against such a contingency
      through the following single line addition of new code
      . if (pct_used + pct_misc > 100.0 || pct_misc < 0) ...
      
      The check for less than zero is not actually necessary
      as long as the source numbers remain unsigned. However
      should they ever become signed, we'll have protection.
      
      [ Most of the changes in this commit simply separate ]
      [ a variable's definition from its associated logic. ]
      
      Reference(s):
      #64
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: address a Debian wishlist NLS man page suggestion · e3c729ad
      Reference(s):
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865689
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • NEWS: add issue and bugzilla references where possible · 2c88d03e
      And we repositioned the kill line (Debian #854407) for
      alphabetic integrity and conformance with newlib NEWS.
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  10. 14 Aug, 2017 1 commit
    • top: refresh interval accepts non-locale decimal value · d9c4b6b0
      For the past 3 years top has fully honored that locale
      LC_NUMERIC setting which impacts his refresh interval.
      For the past nearly 5 years top has saved that refresh
      value in a locale independent form in his config file.
      
      With this commit we'll intentionally break top so that
      a comma or period will be accepted for the radix point
      regardless of what that LC_NUMERIC may have suggested.
      
      The current locale LC_NUMERIC will, however, determine
      how the delay interval is displayed in the 'd' prompt.
      
      [ This position is better than the approach employed ]
      [ by those coreutils 'sleep' and 'timeout' programs. ]
      [ Both claim to permit floating point arguments. But ]
      [ neither one will accept the comma separator should ]
      [ the locale be a country that in fact uses a comma. ]
      
      Reference(s):
      !50
      
      Prototyped by: Jan Rybar <jrybar@redhat.com>
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      Jan Rybar committed
  11. 04 Jul, 2017 2 commits
    • top: fixing command line parsing errors is now a habit · ac76e4db
      Ok, I admit it. I'm now tired of cleaning up after me.
      
      This is the 3rd related tweak after that '-1' argument
      was originally introduced. And with this patch we will
      once again properly honor the '-o' and '-u|U' switches
      without a need to be followed by an additional switch.
      
      [ one can follow my unfortunate trail of alterations ]
      [ beginning with my most recent fix referenced below ]
      
      Reference(s):
      commit 4b44aebd
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: ensure necessary proc_t support if '-U' filtering · 09982256
      While the effective user id would always be present in
      each proc_t, thus supporting 'u' filtering, other user
      ids would only be present if /proc/$$/status was read.
      
      This commit just puts the 'master' branch top on a par
      with the 'newlib' branch when user filtering with 'U'.
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  12. 04 Jun, 2017 1 commit
    • top: correct functioning of the '-p' command line args · 4b44aebd
      With the introduction of a new '1' command line toggle
      I have gone and broken a provision of the '-p' command
      line switch (pids monitoring). Multiple pids could not
      be specified through the use of comma delimited lists.
      
      Thus, this commit simply corrects that newly added bug
      which was born in the 'adjustment' commit shown below.
      
      Reference(s):
      . adjustment to '-1' implementation
      commit 909b37d7
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  13. 22 May, 2017 6 commits
    • sysctl: Print lines longer than 1024 chars · 3fd84670
      as well do not open /proc/sys files if only the names of the
      system control names of the kernel parameters should be shown.
      Avoid leaking tmpname in case of a pattern mismatch.
      
      Signed-off-by: Werner Fink <werner@suse.de>
      Dr. Werner Fink committed
    • top: address the argument parsing quirk involving '-h' · c409f5a4
      There exists the possibility that a 'putp' call can be
      issued before the 'setupterm' invocation has occurred,
      as is reflected in a bugzilla report referenced below.
      
      Strangely, such a SEGV isn't always triggered as logic
      would suggest it ought to be. I experienced a fault in
      these environments with the associated curses version:
      . archlinux, procps-ng 3.3.12, ncurses 6.0.20170429
      . fedora-25, procps-ng 3.3.10, ncurses 6.0.20160709
      . opensuse-42.2, procps-ng 3.3.9, ncurses 5.9.20140201
      . gentoo, procps-ng 3.3.12, ncurses 6.0.20150808
      . slackw-14.2, procps-ng 3.3.12, ncurses 6.0.20160910
      
      Whereas under these environments there was no problem:
      . ubuntu-17.04, procps-ng 3.3.12, ncurses 6.0.20160625
      . debian-test, procps-ng 3.3.12, ncurses 6.0.20161126
      . mageia-5.1, procps-ng 3.3.9, ncurses 5.9.20140323
      
      [ as an aside, the expected result in the bug report ]
      [ is incorrect and should mention the '1' parameter. ]
      
      [ however, until release 3.3.13 when the '1' becomes ]
      [ a valid switch, numbers are not detected when used ]
      [ with any switch which doesn't require an argument. ]
      
      [ you're welcome to treat that as a separate bugglet ]
      
      Reference(s):
      https://bugzilla.redhat.com/show_bug.cgi?id=1450429
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • NEWS: update/alphabetize enhancements for next release · 292bd233
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • ps: have now added the NUMA node field display support · 00820351
      [ this patch has been adapted from the newlib branch ]
      
      Reference(s):
      #58
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: now includes that NUMA node field display support · 1422c219
      [ this patch has been adapted from the newlib branch ]
      
      Reference(s):
      #58
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • library: set stage for NUMA node field display support · 1a2ec039
      In response to that suggestion referenced below, these
      changes allow display of task/thread level NUMA nodes.
      
      Currently, only the 'top' program offers any NUMA type
      support and it is limited to the Summary Area display.
      With this commit both the 'top' and 'ps' programs will
      be able to display NUMA nodes associated with threads.
      
      [ this patch has been adapted from the newlib branch ]
      [ and implemented so as to preserve the existing ABI ]
      
      Reference(s):
      #58
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed