Skip to content

Conversation

movitto
Copy link
Contributor

@movitto movitto commented Sep 24, 2013

No description provided.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.02%) when pulling 25e4f39 on movitto:fstab-formatting into 74e5216 on ManageIQ:master.

@jrafanie
Copy link
Member

@movitto How does this pull handle empty lines or whitespace only lines? The motivation to this change was to preserve comments and any empty lines so we can possibly wrap changes to the fstab in comments similar to how other tools do and at the same time not lose any comments/whitesapce that other tools added.

@jrafanie
Copy link
Member

@brandondunne Thoughts?

@bdunne
Copy link
Member

bdunne commented Sep 27, 2013

@jrafanie This sounds a lot like my hosts file changes here: #65
I think they follow the same whitespace / comment rules. I'd like to see an example of the serialization thing you were talking about yesterday. Maybe the two can share the dump and load code.

@movitto
Copy link
Contributor Author

movitto commented Sep 30, 2013

@jrafanie comment lines are preserved, will look into preserving comments on lines w/ content and empty lines.

Am fine w/ sharing / reusing code, less to maintain.

@movitto
Copy link
Contributor Author

movitto commented Oct 1, 2013

As discussed via email, deferring this for a bit and looking into http://augeas.net/

@jrafanie
Copy link
Member

jrafanie commented Oct 2, 2013

@movitto @brandondunne augeas feels like the wrong tool for the job. It has ruby bindings but why do we need a c extension for something we will may use so infrequently and thus who cares if we use slow pure ruby... It might be worthwhile implementing a basic pure ruby code for each file type as we need them.

@movitto
Copy link
Contributor Author

movitto commented Oct 2, 2013

@jrafanie I feel the case for using it would be it would take care of all the details of parsing and writing the files in question. We'd just have to call out to augeas whenever we'd want to read or write to /etc/fstab or /etc/hosts and wouldn't have to worry about the specifics of those file formats.

Agree that adding a platform specific dependency would be a major drawback to this though. Suppose it comes down to how much we could leverage this for. For the time being since we're only doing simple modifications to these two files, agree it probably would make sense to roll our own, but if we need more and/or more complicated config file parsing it would make sense to revisit

In any case will look into the remaining issues and update shortly.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.02%) when pulling 0223e0f on movitto:fstab-formatting into d445353 on ManageIQ:master.

@movitto
Copy link
Contributor Author

movitto commented Oct 8, 2013

@jrafanie @brandondunne updated

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the need for a line_number or even the columns_lengths or the why we need to separate out the comments from entries.

Maybe I'm missing something.

I believe @entries could contain all lines

  1. regular ones having a device - these are treated as they always have on read and write
  2. ones with a comment
  3. blank ones (ones without a device or comment)

We can then read them and store them in @entries and do the right thing with setting the entry attributes by only setting the relevant attributes, such as comments only having the comment attribute, device ones having the other attributes set, and blank lines having nothing set.

Then, when we want to write them, we just loop through @entries one line at a time, writing normal entries as we do now, writing entries with a comment as the comment, and ones without a command or a device as an empty line.

Thoughts?

@coveralls
Copy link

Coverage Status

Coverage decreased (-2.09%) when pulling 505029a on movitto:fstab-formatting into 614e93d on ManageIQ:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling fb277a3 on movitto:fstab-formatting into 614e93d on ManageIQ:master.

@movitto
Copy link
Contributor Author

movitto commented Oct 23, 2013

@jrafanie updated to incorporate your feedback. Took a little while to tidy up the code while handling all the edge cases but believe I've got them all (as verified by the specs).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can use unless comment.blank?. ActiveSupport is available in this gem.

@Fryguy
Copy link
Member

Fryguy commented Oct 25, 2013

@movitto I had a few style comments, but otherwise this looks great!

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling 8c421b9 on movitto:fstab-formatting into 614e93d on ManageIQ:master.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This column_lengths local variable is confusing because we have a reader method column_lengths and a instance variable column_lengths.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.05%) when pulling 03c85f0 on movitto:fstab-formatting into 614e93d on ManageIQ:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.05%) when pulling 03c85f0 on movitto:fstab-formatting into 614e93d on ManageIQ:master.

@movitto
Copy link
Contributor Author

movitto commented Oct 30, 2013

@jrafanie updated

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider making this formatting string a method since it wasn't obvious what this was doing at first.

def write!
  ...
          content << entry.columns.map.with_index do |column_value, i|
            right_pad(column_value, @column_lengths[i])
  ...
end

def  right_pad(column_value, desired_length)
  "%-#{desired_length}s" % column_value
end

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe @columns_lengths could instead be @maximum_column_lengths or something similar to make this more clear?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or, preferably use the Ruby methods .ljust and .rjust instead of the sprintf format style.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Space after the comma.

@jrafanie
Copy link
Member

jrafanie commented Nov 5, 2013

I have only minor final comments. I like how you split up the logic into small methods but I believe there are few more things we can do to make it a bit more understandable, especially around the string padding we do in #write! and the calculating the maximum length of each column for the file on read (refresh) to enable the padding (at #write!).

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.05%) when pulling b15a687 on movitto:fstab-formatting into 614e93d on ManageIQ:master.

@jrafanie
Copy link
Member

jrafanie commented Nov 8, 2013

@Fryguy looks good to me. Did you want to review the string padding in formatted_columns?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indent is off here (3 spaces instead of 2). Also needs a space after the comma. Code-wise this looks good though.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) when pulling 5a10c68 on movitto:fstab-formatting into ecf649d on ManageIQ:master.

@movitto
Copy link
Contributor Author

movitto commented Nov 12, 2013

@jrafanie @Fryguy updated

@Fryguy
Copy link
Member

Fryguy commented Nov 12, 2013

Looks good to me. @jrafanie?

Fryguy added a commit that referenced this pull request Nov 22, 2013
Preserve comments and format generated whitespace in fstab
@Fryguy Fryguy merged commit 0549613 into ManageIQ:master Nov 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants