Sublime Text Can't Understand Gets.Chomp

Sublime text can't understand gets.chomp

Sublime can't handle interactive input on its own. You can either run your script through SublimeREPL or create a customized build system to open a command prompt and then run the code. Fortunately, this isn't too difficult. Create a new file in Sublime with the following contents:

{
    "cmd": ["start", "cmd", "/k", "c:/ruby193/bin/ruby.exe", "$file"],
    "selector": "source.ruby",
    "shell": true,
    "working_dir": "$file_dir"
}

Save it as Packages/User/Ruby_cmd.sublime-build, where Packages is the directory opened when selecting Preferences -> Browse Packages.... Select Tools -> Build System -> Ruby_cmd, and run your file with CtrlB.

This should work on all versions of Windows from XP on up. It is not intended for OSX or Linux, though, as they don't have the start and cmd programs...

changing a variable using gets.chomp()

The gets method will bring in any amount of text but it will terminate when you hit 'Enter' (or once the STDIN receives \n). This input record separator is stored in the global variable $/. If you change the input separator in your script, the gets method will actually trade the 'Enter' key for whatever you changed the global variable to.

$/ = 'EOF' # Or any other string
lines = gets.chomp
> This is
> multilined
> textEOF
lines #=> 'This is\nmultilined\ntext'

Enter whatever you want and then type 'EOF' at the end. Once it 'sees' EOF, it'll terminate the gets method. The chomp method will actually strip off the string 'EOF' from the end.

Then write this to your text file and the \n will translate into new lines.

File.open('newlines.txt', 'w') {|f| f.puts lines}

newlines.txt:

This is

multilined

text

How to use chomp

chomp removes the trailing newline from the argument. Since none of your four fields should actually contain a newline, this is probably something you want to do for the purposes of data processing. You can remove the newline with chomp before you even split the line into fields, and then add a newline after each record with your final print statement:

while (<>) {
    chomp; # Automatically operates on $_
    my @flds = split /,/;
    DO STUFF HERE;
    ETC;
    print join(",", @flds[0,1,3,2]) . "\n"; # switches 3rd element with last
}

After editing my file via Ruby methods, strange characters appeared

I have a hunch—but can't test it since I'm not at a computer—that File#truncate doesn't reset the File object's internal "cursor." Since you did file.read the cursor is at the end of the file (say, 500 bytes from the beginning). truncate deletes everything in the file but the cursor is still at offset 500, so when you write to the file it starts writing at that position, and the preceding bytes are all set to 00 (NUL).

When you open the file in Atom, it chooses to not display those 00 bytes. (If you can configure Atom to display invisible characters, you should. A text editor should never hide non-printable characters.) Sublime, on the other hand, sees all the 00s and decides to display the file as a binary file in a hex view.

The fact that the first three non-zero bytes shown in Sublime are 76 61 72—the ASCII codes for var—would seem to support this theory.

I think the easiest solution would be to call file.rewind before file.truncate or file.write:

File.open(file_name, 'r+') do |file|
  file_content = file.read
  file_content.sub!("var #{current_name} = ", "var #{new_name} = ")
  file_content.gsub!("#{current_name}.", "#{new_name}.")

  file.rewind
  file.truncate(0)
  file.write(file_content)
end

A better solution, perhaps, would be to embrace the prior invention of the wheel and use sed or awk for this.

---

Related Topics