1. 19
  1. 11

    There is also this less specialized tool:

    column --table /etc/fstab
    1. 5

      But that also spreads the fields in the comments out, right?

      1. 3

        Ah, good point!

        Maybe worth mentioning. I was kind of wondering what I was forgetting. I think I removed the comments I had because of this.

        Congratulations with a new tool!

        1. 2
           gawk '/^#/ { print $0 } !/^#/ { print $0 | "column --table" }' < /etc/fstab

          This will still group your comments up above your fstab entries, so I think this specific tool (or really any real programming language) will be required to do something like this as you’d need to track where lines started and update the table width.

          1. 3

            This picked my curiosity, could it be solved using tools installed by default on my system?

            I managed to get this, but probably a shorter solution without perl is possible, if one is willing to write some loops in bash:

            $ perl -wnle 'BEGIN{open($fmt, "<&", 5) or die("cannot");}; print, next if /^#/; next if /^\s*$/; $l=<$fmt>; chomp $l; print $l;' fstab 5< <(grep -v '^#' fstab|column -t)
            # Static information about the filesystems.
            # See fstab(5) for details.
            # <file system> <dir> <type> <options> <dump> <pass>
            # /dev/nvme0n1p2 LABEL=root
            UUID=2bb3c21b-dc8f-401e-991b-66afd7301cb7  /      xfs   rw,relatime,inode64,logbufs=8,logbsize=32k,noquota                                                         0  1
            # /dev/nvme0n1p1 LABEL=boot
            UUID=1815-DD5D                             /boot  vfat  rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro  0  2
            1. 7

              picked my curiosity

              FYI, it’s piqued – the more you know!

        2. 1

          Shouldn’t it? I think it makes more sense for the field headers to be spread out too, indicating their associated columns directly. That’s how I format my fstab when I do it manually.

          1. 2

            That could actually be nice, but surely you don’t wish to spread out the rest of the comments?

      2. 2

        Ah, I didn’t realize the author posted this! I filed an issue with a logo suggestion.

        1. 1

          I updated the logo. :)

        2. 1

          It’s a neat little tool, though the Go coding style is pretty…odd

          1. 1

            There are no external dependencies and it’s relatively fast. What do you find odd?

            1. 4

              […] the Go coding style is pretty…odd

              What do you find odd?

              …the Go coding style, like I said.

              I don’t have any qualms with the codebase/project overall, or with it not having external dependencies or being relatively fast. I meant that the actual code (e.g. in main.go) itself is odd. For instance, flags are being parsed manually and there’s a usage() function invoked to print the program details; in Go, there’s a standard library package called flag that takes care of all this, and it is used in many Go programs because it’s safe. You can even override the Usage function to make your own custom help printout if you wanted to.

              1. 3

                I think for a program of this size i personally like it better that it is self-contained. We could probably go crazy with this and make every line a single package, but sooner or later go is going to hit its own leftpad drama.

                But that’s just my personify personal opinion.

                As for the coding style, I don’t work with go but I could read the code easily. Which of the actual code is not what you would usually see in go? I mean, aside from the dependency.

                1. 14

                  Meeting a suggestion to use a dependency with “but but leftpad” is pretty reductionist. But the suggestion is not to bring in a dependency. The suggestion is to use the flag package, which is part of the standard library. The standard library is already being used here anyway.

                  But I wouldn’t find the code that odd. Maybe a little. But it only has one flag. So it can be handled pretty simply.

                  1. 8

                    I have no idea what is going on. It really feels like some people are reading every other word I write, and it’s getting frustrating.

                    […] that it is self-contained. We could probably go crazy with this and make every line a single package

                    I am not suggesting adding a dependency. The flag package is part of the Go standard library. fstabfmt is self-contained now, and it would continue to be self-contained even if the flag package was used.

                    Which of the actual code is not what you would usually see in go?

                    Again…as I mentioned before: manually parsing/handling flags is not something you usually see in Go. It is recommended practice to use the standard library flag package, because it does a good job of it. It’s not a severe infraction, it’s just an observation of mine that I remarked as odd.

                  2. 2

                    I agree that the flag package could have been used, but I don’t think it would have provided much benefit.

                    My favorite for flag handling is the urfave/cli package, btw.

                    1. 3

                      Fair enough. I was mostly curious about if there was a reason to not use the typical packages that I hadn’t thought of. No problem at all if you simply hadn’t felt like it lol