require 'shell'
sh = Shell.new
sh.verbose = false
sh.debug = false
print sh.system('date')
Expected output
Wed Nov 10 13:08:09 EST 2021
Observed output
shell(#<Th:0x00007fd016064058 run>): /bin/date
Wed Nov 10 13:08:09 EST 2021
The unwanted line comes from Shell::CommandProcessor#notify
After some investigation there seems to be a confusing design flaw (or feature?) in Shell. Initally it seems you should be able to mutate verbose and debug on an instance of Shell, but it turns out the root notify method itself lives in the class, not the instance.
Hence instance level settings will only have limited effect, as the class method Shell.notify will be unaware of instance settings.
Solution - use class-level settings instead:
Shell.verbose = false
Shell.debug = false
Output will now be only:
Wed Nov 10 13:08:09 EST 2021
Related
I am using git-bash on a Windows system.
The Windows clock shows local time, but inside git-bash everything is in GMT time:
$ date
Mon Mar 31 16:08:57 GMT 2014
Also setting TZ will not change things:
$ TZ="Europe/Berlin" date
Mon Mar 31 16:09:01 GMT 2014
Similarly all times it git log are GMT only.
Is there a way to set the correct timezone in git-bash?
On Windows the TZ variable seems to work differently.
To get the German timezone you have to write:
TZ=GST-1GDT date
If you set it to some "invalid" value like "Europe/Berlin" it will default to GMT.
The same seems to happen on my system when TZ is not set at all.
With the above setting I get Thu Apr 17 16:23:23 GDT 2014 which is not exactly the same as Thu Apr 17 16:23:23 CEST 2014, but at least the time looks right.
Same problem here in my script. Windows was showing 15:47 and the "date" command in gitbash was answering 13:47.
export TZ="CEST-2"
This fixed the problem for me. I wanted Paris time.
It looks Dir.entries("dir") updates the dir's atime on Linux.
irb(main):042:0> File::Stat.new("/tmp/tmp2").atime
=> Thu Aug 25 09:16:36 -0700 2011
irb(main):043:0> File::Stat.new("/tmp/tmp2").atime
=> Thu Aug 25 09:16:36 -0700 2011
irb(main):044:0> Dir.entries("/tmp/tmp2")
=> ["file1", "..", ".", "dir1"]
irb(main):045:0> File::Stat.new("/tmp/tmp2").atime
=> Thu Aug 25 09:16:49 -0700 2011
Is it possible to get the dir entries without changing the atime of itself in Ruby?
There's no way to do it in Ruby, or even in general. Reading any file or directory, by any method, will always update its atime. (Unless the whole filesystem is set to not use atimes with a mount flag, like noatime or relatime.)
require 'java'
if ARGV.length == 0
puts "Usage: jruby change_timezone.rb America/Toronto"
exit
end
old_zone = File.read("../../../etc/timezone")
puts old_zone
time1 = Time.now
puts "Current Time:"+time1.localtime.to_s
new_zone = ARGV[0]
open('../../../etc/timezone','w') do |f|
f.puts new_zone.to_s
f.close
end
new_zone = File.read("../../../etc/timezone")
puts new_zone
time2 = Time.now
puts "Updated Time:"+time2.localtime.to_s
Above is a ruby script I wrote to change the timezone configuration on ubuntu. It does change the configuration file properly, however, the output for the script is Not as expected.
Assume the default value for timezone is America/Toronto.
Now run the command, jruby change_timezone.rb Asia/Chongqing, then here's the output:
America/Toronto
Current Time:Thu Jul 07 14:43:23 -0400 2011
Asia/Chongqing
Updated Time:Thu Jul 07 14:43:23 -0400 2011 (My Note: +0800 expected!!!)
Continue with the command, jruby change_timezone.rb Europe/Amsterdam, end up with the following:
Asia/Chongqing
Current Time:Fri Jul 08 03:18:25 +0800 2011 (My Note: it actually got updated from last run!!!)
Europe/Amsterdam
Updated Time:Fri Jul 08 03:18:25 +0800 2011 (My Note: +0200 expected!!!)
Go further with, jruby change_timezone.rb Europe/Amsterdam (My Note: in effect repeating the last command), and get the following:
Europe/Amsterdam
Current Time:Thu Jul 07 21:21:27 +0200 2011
Europe/Amsterdam
Updated Time:Thu Jul 07 21:21:27 +0200 2011
Can someone figure out why it didn't work as expected?
For almost any Linux distribution '/etc/localtime' is a symlink to the correct timezone file or is the effective timezone file. The file '/etc/timezone' is used by 'dpkg-reconfigure tzdata' command to generate (or symlink) the effective timezone file at '/etc/localtime'. Finally, timezone files are located at '/usr/share/zoneinfo/'. In summary I think you miss one final step after the file '/etc/timezone' get changed. It's to run:
$ dpkg-reconfigure tzdata
So, I wrote a quick thread example for myself, using the ruby docs for thread:
puts "Hello World"
test = Thread.new do
while true
puts Time.now
end
end
puts "Goodbye World"
I would EXPECT this code to run forever, printing "Hello World", a few time stamps, goodbye world, and then a whole bunch of time stamps, until I manually break the code.
Instead, what I get is something like:
Hello World
Fri Aug 06 09:08:27 -0400 2010
Fri Aug 06 09:08:27 -0400 2010
Fri Aug 06 09:08:27 -0400 2010
Fri Aug 06 09:08:27 -0400 2010
Fri Aug 06 09:08:27 -0400 2010
Fri Aug 06 09:08:27 -0400 2010
Fri Aug 06 09:08:27 -0400 2010
Fri Aug 06 09:08:27 -0400 2010
Fri Aug 06 09:08:27 -0400 2010
Goodbye World
And then the program terminates. I'm REALLY confused here. Do threads terminate as soon as the next line of code would have started? Do they time out? I've tried adding
sleep 1
before and after the puts statement...but that just means that the thread prints less time stamps (if the sleep is before the puts, it prints nothing, just hello and goodbye, if after, it prints exactly one time stamp before exiting).
I don't have the most threading experience...but this seems really unintuitive to me... Am I doing something wrong? Using threads incorrectly? Am I doing it right but am confused about what threads are/do?
puts "Hello World"
test = Thread.new do
while true
puts Time.now
end
end
puts "Goodbye World"
test.join
Calling the .join method on an instance of Thread class will make the program stop and wait for that thread to complete.
Not sure about the Ruby-specific stuff. Apart from that, generally when the script ends, the program ends -- in many cases, all the threads get killed off before the interpreter exits.
Threads are just a way to do a couple of things at once -- you shouldn't count on them to keep your program alive, especially once the main thread (the one that started everything) dies. If you want to wait for a thread to finish, most languages have a "join" or "wait" function that'd let the thread finish. But once the main thread's done, all bets are off.
With that said, Ruby may decide to let threads run til they finish. Like i said, not sure about that, cause it's Ruby-specific. But from the look of things, it'd seem not.
I am refactoring some code for a Ruby library. This code includes a Date parser.
One of the tests was to parse this string "2008-02-20T8:05:00-010:00" which is supposed to be ISO 8601.
The previous code would actually output: "Wed Feb 20 18:05:00 UTC 2008".
My new code outputs that: "Wed Feb 20 16:05:00 UTC 2008".
My question is: which one is the right one?
Time.parse in Ruby gives the second one. But again, I want to be 100% sure that the previous code AND test were buggy.
Which one is right? (By maybe parsing the string with a library in another language? - I only know Ruby.)
The correct UTC time is 1805. The time group indicates 0805 in zone -10, so to get UTC add the 10 to the given time. Thus 1805. Since 1805 is less than 2400 it's the same day.
If your code is giving 1605, then you almost certainly have the timezone set incorrectly to zone -8, which happens to be Pacific Standard Time.
Aha, looks like your input format is messed up. Observe:
irb(main):003:0> Time.parse("2008-02-20T8:05:00-010:00")
=> Wed Feb 20 08:05:00 -0700 2008
I happen to be in zone -7 so it's suiting that to my locale. But
irb(main):004:0> t=Time.parse("2008-02-20T8:05:00-010:00")
=> Wed Feb 20 08:05:00 -0700 2008
irb(main):005:0> t
=> Wed Feb 20 08:05:00 -0700 2008
irb(main):006:0> t.getutc
=> Wed Feb 20 15:05:00 UTC 2008
I'm getting an unexpected result. Now observe:
irb(main):007:0> t=Time.parse("2008-02-20T8:05:00-10:00")
=> Wed Feb 20 11:05:00 -0700 2008
irb(main):008:0> t.getutc
=> Wed Feb 20 18:05:00 UTC 2008
There's the expected result. See the difference? First example vs second:
irb(main):004:0> t=Time.parse("2008-02-20T8:05:00-010:00")
irb(main):007:0> t=Time.parse("2008-02-20T8:05:00-10:00")
I took the spurious extra 0 out (which I certainly didn't notice either) and whoosh, it works.
I know this is pretty old, but I just ran across it.
I'll bet that something somewhere is interpreting 010 as an octal number with the value 8. Perhaps it's a bug in the implementation of Time.parse()?