Rubyと筋肉とギターとわたし

筋トレが仕事です

【Rails】heroku containerをリリース時にアプリがクラッシュする

f:id:rdwbocungelt5:20181009115813j:plain

どうもてぃです。

一ヶ月ほど前に僕もパパになり、可愛い娘の寝顔を見ながら出勤する毎日を過ごしております。

天使すぎてホント癒やされる。

それはさておき、今回はherokuへコンテナデプロイした際に少しハマったので、同じ現象に悩まれてる方へ向けて記事を書きたいと思います。

heroku container

今回始めてheroku containerを使用してみたんですが、めちゃくちゃ簡単でした。

プロジェクトをDockerで作成しているなら是非やってみてください。

ただ、気をつけていないとハマる部分は割とあります。

以下デプロイ手順参考。

devcenter.heroku.com

個人的にherokuとgoogleはリファレンスが最強だと思ってます。

そんなに難しい英語も書いてないですしね。

はまった現象

heroku containerのデプロイ時に気をつけないといけないのが、デプロイしたいコンテナ以外のコンテナが動いている場合は壊すか止めるかしないとアプリケーションクラッシュの原因になることです。

僕は開発が終わったら毎回コンテナを潰してるので、 docker ps -a で出てきたものは全て削除してます。

総削除は以下のコマンド。

$ docker rm `docker ps -a -q`

最近はdockerのCUIも増えてきてるのでそれを使うのも有りかもですね。

ちょーっと重いですがvimライクに操作できるので以下を使ってます。

github.com

コンテナ削除後、デプロイ手順を踏んで普通にデプロイ。

$ heroku container:push web

$ heroku container:release web

大抵はこれで上手く行きますが、アプリケーションを開いたところクラッシュしてました。

以下がログ(heroku logs --tail

2019-09-04T01:35:25.823858+00:00 heroku[web.1]: Starting process with command `rails server -b 0.0.0.0`
2019-09-04T01:35:31.697033+00:00 heroku[web.1]: State changed from starting to crashed
2019-09-04T01:35:31.606898+00:00 app[web.1]: A server is already running. Check /myapp/tmp/pids/server.pid.
2019-09-04T01:35:31.608944+00:00 app[web.1]: => Booting Puma
2019-09-04T01:35:31.608946+00:00 app[web.1]: => Rails 5.2.3 application starting in production
2019-09-04T01:35:31.608948+00:00 app[web.1]: => Run `rails server -h` for more startup options
2019-09-04T01:35:31.608949+00:00 app[web.1]: Exiting
2019-09-04T01:35:31.684704+00:00 heroku[web.1]: Process exited with status 1
2019-09-04T01:35:33.527454+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/robots.txt" host=line-bot.herokuapp.com request_id=f2475bec-d670-4f3b-9395-407e57a997c5 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https
2019-09-04T01:35:34.134860+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=d61341cf-9cc6-4290-9ece-55689779e7ef fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https
2019-09-04T01:37:22.870909+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=9deb4679-3509-4dbd-bd45-3722609ec387 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https
2019-09-04T01:37:25.542657+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=72fa644f-8a98-4e96-a20b-82e01de4b659 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https
2019-09-04T01:37:28.998503+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=dd9d8c5e-7f57-4adf-816a-e68782ca8b83 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https
2019-09-04T01:37:29.463016+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/favicon.ico" host=line-bot.herokuapp.com request_id=b0201b8e-efad-41f6-890c-42c4726c3922 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https

マイグレーションもやったし、DBもインスタンスも有料化してるし。。。

もしかしたらなんかエラーが出てるのにそのままデプロイしちゃったかも?とおもってローカルで確認してみたけどそんなこと全く無い。。。

原因不明でした。

よくあるエラーと同じだった

今回の問題はDockerじゃなくてもローカルでも起きる問題が、Dockerコンテナをデプロイしたがゆえに発生した問題でもありました。

どういうことかというと、ローカルで普通に開発している場合(Dockerの有無にかかわらず)、Railsサーバーを落とした際に何かの不具合で tmp/pids/server.pid が残っていると Process exited with status 1 が発生して起動できないことがあります。

これがまさに今回の原因で、コンテナをデプロイする際に、ローカルプロジェクトに tmp/pids/server.pid が残っていると一緒にherokuへデプロイされちゃうと。

エラーメッセージがまさにそれを物語っていて

2019-09-04T01:35:25.823858+00:00 heroku[web.1]: Starting process with command `rails server -b 0.0.0.0`
2019-09-04T01:35:31.697033+00:00 heroku[web.1]: State changed from starting to crashed
2019-09-04T01:35:31.606898+00:00 app[web.1]: A server is already running. Check /myapp/tmp/pids/server.pid.
2019-09-04T01:35:31.608944+00:00 app[web.1]: => Booting Puma
2019-09-04T01:35:31.608946+00:00 app[web.1]: => Rails 5.2.3 application starting in production
2019-09-04T01:35:31.608948+00:00 app[web.1]: => Run `rails server -h` for more startup options
2019-09-04T01:35:31.608949+00:00 app[web.1]: Exiting
2019-09-04T01:35:31.684704+00:00 heroku[web.1]: Process exited with status 1

A server is already running. Check /myapp/tmp/pids/server.pid. で、デプロイはできているけど、processが既にあるんすわ〜ってherokuが認識してしまっていたということですね。

解決策

とても簡単で

$ rm tmp/pids/server.pid

$ heroku container:push web

$ heroku container:release web

これで解決です。

はまるところはあるんですが、一度出来てしまえばcontainerデプロイの便利さはやめられないです。

【レビュー】ロウヤの170度リクライニングオフィスチェアを購入した

f:id:rdwbocungelt5:20190916163735j:plain

どうもてぃです。

このたび、リモートワークが増える可能性があるということで、作業環境の整備をするはじめの一歩として椅子を購入しました。

願わくばハーマンミラーアーロンチェアを買いたかったんですが、如何せん高い。

でも、アーロンチェアは会社で使っていてちょっとだけ不満もあったので、その不満を満たすべく自分の要望にあった椅子を探し求めた結果、今回の椅子に決めました。

以前使っていた椅子

実家にいた時に買ったのがこれ。

item.rakuten.co.jp

www.amazon.co.jp

結果から言うと安物買いの銭失いでした。なんでこんなにレビューが良いのか謎なんですよねぇ。

このタイプ(ハイバックっていうのかしら?)の椅子、僕には全く合わなかったです。

主な理由としては、背もたれ。一息するとき、フーッと、もたれかかっても、身体にフィットしないというか背中全体を支えてくれない。

あと、もたれたときに背もたれが後頭部の高さまであるので、髪の毛にワックスをつけてると気になって安易に背中をつけられない、リラックスできないんです。

挙句の果てには半年で接続部分がもげてしまい、背もたれを外さないといけない始末。

現在は無様な姿と成り果て、粗大ごみとして出す機会を毎回失っているので、仕方なくギター用の椅子として使用しています。

f:id:rdwbocungelt5:20190916151608j:plain
無様な姿に変わり果てた汚い椅子

今回購入した椅子

こちらです。

今見たらクソたけぇ。

www.low-ya.com

楽天のスーパーセールで安くなっていたのですが、セール時に買い損ね残念に思っていたところ、公式を見たらたまたまスーパーセールよりも安くなっており衝動的にポチりました。

セール時には17000円くらいで購入できたのはラッキーでしたね。

使用し始めて3ヶ月ほど経過したので、良い点・悪い点を書いていこうと思います。

良い点

その1:組み立てが割と簡単

パーツがいちいちデカイのが難点ですが、デカイ分組み立ては結構簡単でした。

所要時間15〜20分ほど。

レビューで30分ほどかかると書いてたので、想定内に収まってよかったです。

その2:身体にフィットする

フィットします。前の子よりも断然いいです。

メッシュを購入して、高反発なのにフィットする。すばらC。

僕は身長180cmと割と大きめで、ハイバック式が嫌いという性質をもっていますが、リクライニングを調整すると背筋も伸びて頭も後ろにつかないし身体が包まれる感じがするのはマジで神です。

マジで神。

その3:腰が痛くならない

これも前述の通り、身体にフィットするので腰が痛くなりません。

僕の弱点は腰なので、これを満たせているはかなり大きいです。

つーか、椅子で腰悪くするって本末転倒だわ。

その4:リクライニング最高

仕事中に詰まったりちょっと休憩するときに、フルリクライニングできるのはマジで良い。

レビューにはありましたが、「この椅子に座ると眠くなる」はあながち間違ってないかも。

ただ、僕は仕事用に使ってるのでいまのところその兆候はないです。

フットレストもあって寝心地も割といい。でも、寝る用途として買ったわけではないので気をつけないとですね。

悪い点

その1:デカい

良い点でも上げてますが、デカいです。

僕は男性なので問題ないですが、女性だと一人で組み立てるのに苦労しそう。

あと、引っ越しの時割と面倒臭いかもしれないですねぇ。。。

その時はもっと稼いで、売り払ってアーロンチェア買おうかな。

その2:油臭い

新品あるあるなのかな?

到着してダンボールを開いた時に油臭く、組立後も一週間ほど油臭かったです。

組み立てるときにも思いましたが、接続部の部品(フットレストや足)に結構油がついてました。

仕方ないんですけどね。。。組み立て時にはちゃんと軍手をした方がいいです。

組立て終わった後にアルコール除菌シートで拭いてまわっても一週間前後は臭いが残ったので要注意です。

その3:各部品の品質が良くない

セール時の在庫処分的な商品だからかなーと思ったりしました。

品質については以下

  • 座る部品のメッシュがちょっと破けてた
  • ネジが合わず回すのに結構力が必要だった
  • 左右で接続部の位置が違ったりする
  • フットレストを出し入れするとき、何かに引っかかったりしてコツがいる

いまのところ気になるのはこれくらい。

上3つは時間も経ったのでもう気にしていないです。

ただ、フットレストは困りますね。毎回スムーズに出てこない。

しかも、出し入れの音がうるさい。

さらに、金属部分を触ると油が手に付く。

そんな頻繁にリクライニングして寝転がるわけではないので、いまのところ目をつむってます。

次買う椅子では必ず見るように気をつけたいです。。。

その4:フットレストうるさい

前述通りです。

出し入れがうるさいので、これは品質の問題。。。

次買う椅子では以下略

総評

以上、良い点・悪い点あげてみました。

前の椅子がひどすぎたのもあり、最低限要件が満たされている今回の椅子には総じて今のところ満足してます。

いや、その椅子はマジカスだよ、こっちのが絶対おすすめだよって人がいたら是非とも教えてください。

その時はあなたのアフィリンクを踏ませてください。お願いします。

【PostgreSQL】CloudSQLからエクスポートしたダンプデータをインポートする

f:id:rdwbocungelt5:20181112160913p:plain

どうもてぃ。

最近エンジニア用のアカウントを作成しました。

写真チャラいです。

twitter.com

それはさておき、本番環境と同じデータをローカルに反映させたかったので、DBサーバーのCloudSQLからダンプデータを落としてローカルにインポートしました。

その時の流れを書きたいと思います。

プロジェクトはRailsです。

CloudSQLからCloudStorageへ

使用しているDBデータをCloudStorageへ落とします。

ここに手順を書いてもいいですが、googleのドキュメントのわかりやすさには勝てそうにないのでそちらを参考にしてください。

以下参考。

cloud.google.com

ローカルへインポート

CloudStorageから上記手順で落としたダンプデータをダウンロードします。

その後、psqlコマンドでDB名を指定してインポートします。

この際、先にDBを作って準備しておく必要があります。要注意。

$ bundle exec rails db:create

$ psql DB名 < ~/Downloads/Cloud_SQL_Export_2019~~~~~~~~~

ダウンロードしたダンプデータの保存先は基本Downloadsになっているはず。

違う場合はダウンロードしたパスを指定して上げてください。

ダンプデータのファイル名は上のように、 Cloud_SQL_Export_日付 になっているかと思うので、正しく指定してあげてください。

PG::ConnectionBad - fe_sendauth: no password supplied

準備が整ったと思ったので、サーバーを起動して画面確認したところ上記エラー。

単に database.yml でパスワード設定してないだけでした。

おろかなり。

PG::InsufficientPrivilege - ERROR: permission denied for relation schema_migrations

パスワードを設定して、サーバー起動後画面を表示するとこのエラー。

使用しているユーザーがDBスキーマに対して権限を持ってないとのこと。

以下で解決。

postgres=> \c <database_name>  # 権限を付与するDB名

database_name=> grant all on all tables in schema public to <user_name>  # user_nameは付与するユーザー名

\z で確認するとちゃんと付与されてるっぽかった。

マイグレーションを実行

$ bundle exec rails db:migrate
・
・
・

StandardError: An error has occurred, this and all later migrations canceled:

PG::InsufficientPrivilege: ERROR:  must be owner of relation <table_name>

まだ解決できない。。。

もっかい権限が付与されてるか確認してみると…特定のテーブルだけ権限が変更できてて、他は全く変更できてなかった。

\z じゃなくて、\d の方が見やすかった。だまされた。

なのでテーブルごとに権限を変更した。

postgres=> \c <database_name> 

# user_nameは付与するユーザー、old_user_nameは現在付与されているユーザー
database_name=> select 'alter table ' || schemaname || '.' || tablename || ' owner to <user_name>;'
from pg_tables
where tableowner = '<old_user_name>';

# 上で出てきたものをコピーして貼り付け実行する

すべてuser_nameをownerへ変更できた。

解決

マイグレーションがやっと通りました。

CloudSQLから落としたデータをインポートするとこんなにハマるとは思ってなかった。

今後同じようなことが出てくると思うので備忘録として、また同じような作業をする人へ向けて書きました。

なにかわからないことがあればコメントよろしくお願いします。

【vim】color pickerを使えるようにする

どうもてぃです。

VSCodeAtomでは標準で装備されてるcolor pickerですが、vimにはもちろんついてないです。

調べてみたら、普通にあったので導入してみました。

環境

  • Ubuntu 16.04.5 LTS(elementary OS 0.4.1 Loki)

vCoolor.vim

github.com

こちらですね。

僕は dein.vim をつかってパッケージ管理しているので、

" color picker
call dein#add('KabbAmine/vCoolor.vim')

を追加するだけ。

github上のREADMEにオプションが書いてあるので、必要であれば追記してください。

注意

github.com

上記URLの説明にある通り、

が呼び出されます。

Macの方は気にしなくていいですが、Linux & Windowsの方は気をつけてください。

完成

ノーマルモード:VCoolor と入力するとcolor pickerが呼び出されます。

f:id:rdwbocungelt5:20190606133650p:plain

呼び出すのを楽にしたいので後でキーマッピングしたいと思います。

では。

【Rails】helperで環境変数を使いたい場合

どうもてぃです。

備忘録として残しておきます。

環境変数を設定し、クライアント側で表示するものを変えたいとPMから要望が合ったので、その要件を満たすために実装しました。

実装したとはいっても、そんな大したことはやっていないですが。

実行環境

helperでは環境変数を読み込んでいない

まず前提として、helperでは環境変数は読み込めていないです。

今回、gemの dotenv-rails を使っていますが、設定していた環境変数をhelperやviewで呼び出したのですが、 nil が返ってきました。

module UsersHelper
  def display_user
    current_user.name if ENV['IS_USER_DISPLAY_DEFAULT'] == 'true'
    # => ENV['IS_USER_DISPLAY_DEFAULT']がnilで返ってくる
  end
end

こんな感じ。

.env ファイルに IS_USER_DISPLAY_DEFAULT を設定している状態です。

解決策

至って簡単。

helperのメソッド内で読み込み直せば良い。

module UsersHelper
  def display_user
    Dotenv.overload
    current_user.name if ENV['IS_USER_DISPLAY_DEFAULT'] == 'true'
  end
end

Dotenv.load では環境変数を変更した際に再読み込みされないようなので、 Dotenv.overloadで対応。

これで面倒なクライアントさんの要件を満たすことが出来ました。

めでたしめでたし。

【Rails】docker-composeでrails generateが使えず、Could not find rake ~~~~になる

どうもてぃです。

もうそろそろ梅雨ですね。ジメジメしたのは嫌いです。

今回は docker-compose を使って rails g controller を行うと起こるエラーの対処方法について書こうと思います。

環境

  • Docker version 17.12.0-ce, build c97c6d6
  • docker-compose version 1.20.1, build 5d8c71b

起こったこと

f:id:rdwbocungelt5:20190522160146p:plain

いつもどおり、Dockerfileとdocker-compose.ymlを作成し、イメージのビルド、サーバーの起動まで上手くいきました。

以下がDockerfileとdocker-compose.yml

FROM ruby:2.5
ENV LANG C.UTF-8
ENV APP_ROOT /myapp

RUN apt-get update -qq && \
    apt-get install -y build-essential libpq-dev nodejs postgresql-client && \
    rm -rf /var/lig/apt/lists/*
RUN gem install rails

WORKDIR $APP_ROOT
COPY Gemfile ${APP_ROOT}/Gemfile
COPY Gemfile.lock ${APP_ROOT}/Gemfile.lock
RUN bundle install --path vendor/bundle

ADD . /myapp
version: "3"
services:
  db:
    image: postgres
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: root
    ports:
      - "5432"
    volumes:
      - ./tmp/db:/var/lib/postgresql/data
  web:
    build: .
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -b 0.0.0.0 -p 3000"
    volumes:
      - .:/myapp
      - ./vendor/bundle:/myapp/vendor/bundle:delegated
      - /myapp/tmp/cache
      - /myapp/log
      - /myapp/vendor
      - /myapp/.git
    environment:
      RAILS_ENV: development
      DATABASE_HOST: db
      DATABASE_PORT: 5432
      DATABASE_USER: postgres
      DATABASE_PASSWORD: root
    ports:
      - "3000:3000"
    depends_on:
      - db
    tty: true
    stdin_open: true

ここにのせるとインデントがずれてますが、よくある構成だと思います。

上記の設定を元に環境を作ったあと、 rspec を導入したかったのでいつものコマンドを入力しました。

すると。。。

$ docker-compose run web bundle exec rails g rspec:install
Starting myapp_db_1 ... done
Could not find rake-12.3.2 in any of the sources
Run `bundle install` to install missing gems.

bundle installもうまくいくし、問題なさそうなのに Could not find rake-12.3.2 in any of the sources が出てくる。

対処法

stackoverflowで全く同じ質問していた人がいたので、参考にしてみた。

$ docker-compose run web bundle install --binstubs

# 自分の環境ではvendor/bundle配下に設置
$ docker-compose run web bundle install --path vendor/bundle

さて、ジェネレーターはちゃんと動くのか?

$ docker-compose run web bundle exec rails g rspec:install

Starting myapp_db_1 ... done
Beginning in Rails 4, Rails ships with a `rails` binstub at ./bin/rails that
should be used instead of the Bundler-generated `rails` binstub.

If you are seeing this message, your binstub at ./bin/rails was generated by
Bundler instead of Rails.

You might need to regenerate your `rails` binstub locally and add it to source
control:

 rails app:update:bin           # Bear in mind this generates other binstubs
                                # too that you may or may not want (like yarn)

If you already have Rails binstubs in source control, you might be
inadverently overwriting them during deployment by using bundle install
with the --binstubs option.

If your application was created prior to Rails 4, here's how to upgrade:

  bundle config --delete bin    # Turn off Bundler's stub generator
  rails app:update:bin          # Use the new Rails executables
  git add bin                   # Add bin/ to source control

You may need to remove bin/ from your .gitignore as well.

When you install a gem whose executable you want to use in your app,
generate it and add it to source control:

  bundle binstubs some-gem-name
  git add bin/new-executable

      create  .rspec
      create  spec
      create  spec/spec_helper.rb
      create  spec/rails_helper.rb
Usage:
  rails new APP_PATH [options]

Options:
      [--skip-namespace], [--no-skip-namespace]            # Skip namespace (affects only isolated applications)
  -r, [--ruby=PATH]                                        # Path to the Ruby binary of your choice
                                                           # Default: /usr/local/bin/ruby
  -m, [--template=TEMPLATE]                                # Path to some application template (can be a filesystem path or URL)
  -d, [--database=DATABASE]                                # Preconfigure for selected database (options: mysql/postgresql/sqlite3/oracle/frontbase/ibm_db/sqlserver/jdbcmysql/jdbcsqlite3/jdbcpostgresql/jdbc)
                                                           # Default: sqlite3
      [--skip-yarn], [--no-skip-yarn]                      # Don't use Yarn for managing JavaScript dependencies
      [--skip-gemfile], [--no-skip-gemfile]                # Don't create a Gemfile
  -G, [--skip-git], [--no-skip-git]                        # Skip .gitignore file
      [--skip-keeps], [--no-skip-keeps]                    # Skip source control .keep files
  -M, [--skip-action-mailer], [--no-skip-action-mailer]    # Skip Action Mailer files
  -O, [--skip-active-record], [--no-skip-active-record]    # Skip Active Record files
      [--skip-active-storage], [--no-skip-active-storage]  # Skip Active Storage files
  -P, [--skip-puma], [--no-skip-puma]                      # Skip Puma related files
  -C, [--skip-action-cable], [--no-skip-action-cable]      # Skip Action Cable files
  -S, [--skip-sprockets], [--no-skip-sprockets]            # Skip Sprockets files
      [--skip-spring], [--no-skip-spring]                  # Don't install Spring application preloader
      [--skip-listen], [--no-skip-listen]                  # Don't generate configuration that depends on the listen gem
      [--skip-coffee], [--no-skip-coffee]                  # Don't use CoffeeScript
  -J, [--skip-javascript], [--no-skip-javascript]          # Skip JavaScript files
      [--skip-turbolinks], [--no-skip-turbolinks]          # Skip turbolinks gem
  -T, [--skip-test], [--no-skip-test]                      # Skip test files
      [--skip-system-test], [--no-skip-system-test]        # Skip system test files
      [--skip-bootsnap], [--no-skip-bootsnap]              # Skip bootsnap gem
      [--dev], [--no-dev]                                  # Setup the application with Gemfile pointing to your Rails checkout
      [--edge], [--no-edge]                                # Setup the application with Gemfile pointing to Rails repository
      [--rc=RC]                                            # Path to file containing extra configuration options for rails command
      [--no-rc], [--no-no-rc]                              # Skip loading of extra configuration options from .railsrc file
      [--api], [--no-api]                                  # Preconfigure smaller stack for API only apps
  -B, [--skip-bundle], [--no-skip-bundle]                  # Don't run bundle install
      [--webpack=WEBPACK]                                  # Preconfigure for app-like JavaScript with Webpack (options: react/vue/angular/elm/stimulus)

Runtime options:
  -f, [--force]                    # Overwrite files that already exist
  -p, [--pretend], [--no-pretend]  # Run but do not make any changes
  -q, [--quiet], [--no-quiet]      # Suppress status output
  -s, [--skip], [--no-skip]        # Skip files that already exist

Rails options:
  -h, [--help], [--no-help]        # Show this help message and quit
  -v, [--version], [--no-version]  # Show Rails version number and quit

Description:
    The 'rails new' command creates a new Rails application with a default
    directory structure and configuration at the path you specify.

    You can specify extra command-line arguments to be used every time
    'rails new' runs in the .railsrc configuration file in your home directory.

    Note that the arguments specified in the .railsrc file don't affect the
    defaults values shown above in this help message.

Example:
    rails new ~/Code/Ruby/weblog

    This generates a skeletal Rails installation in ~/Code/Ruby/weblog.

rspecの設定ファイルは作成できたけど、なんかめっちゃ出てる。

要約するとbin関連をupdateしないといけないみたいね。ということでやってみた。

$ docker-compose run web bundle exec rails app:update:bin
# 以下全てOverwriteする

bin関連でOverwriteするかどうか出てくるので全て上書きでおk。

終わりに

念の為、controllerが作成できるか試してみた。

$ docker-compose run web bundle exec rails g controller Home index

特にエラーも警告もなくコントローラー生成できた\(^o^)/

二回も同じことで躓いたので、流石にメモ。

安易にdockerに頼り過ぎないようにしましょうね。

【Linux】xargsに渡したファイルに空白がある場合の削除方法

どうもてぃです。

ちょっとだけハマったのでメモ。

ls, grep, xargs rm

上記のコマンドを組み合わせて、いつもどおり溜まったスクリーンショット画像を削除しようとしました。

すると。。。

$ ls | grep 'Screenshot' |  xargs rm
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-05-08' を削除できません: そのようなファイルやディレクトリはありません
rm: '16-39-46.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-03-14' を削除できません: そのようなファイルやディレクトリはありません
rm: '18-18-42.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-04-18' を削除できません: そのようなファイルやディレクトリはありません
rm: '10-37-00.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-03-12' を削除できません: そのようなファイルやディレクトリはありません
rm: '22-42-45.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-03-07' を削除できません: そのようなファイルやディレクトリはありません
rm: '18-41-14.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-04-16' を削除できません: そのようなファイルやディレクトリはありません
rm: '20-19-58.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-05-06' を削除できません: そのようなファイルやディレクトリはありません
rm: '18-28-44.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-03-01' を削除できません: そのようなファイルやディレクトリはありません
rm: '17-38-51.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-03-12' を削除できません: そのようなファイルやディレクトリはありません
rm: '17-43-33.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-03-06' を削除できません: そのようなファイルやディレクトリはありません
rm: '10-59-12.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-03-26' を削除できません: そのようなファイルやディレクトリはありません
rm: '10-35-37.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-04-28' を削除できません: そのようなファイルやディレクトリはありません
rm: '16-34-29.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-04-04' を削除できません: そのようなファイルやディレクトリはありません
rm: '11-03-00.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-02-08' を削除できません: そのようなファイルやディレクトリはありません
rm: '15-21-58.png' を削除できません: そのようなファイルやディレクトリはありません
rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません
rm: 'from' を削除できません: そのようなファイルやディレクトリはありません
rm: '2019-01-25' を削除できません: そのようなファイルやディレクトリはありません
rm: '14-15-28.png' を削除できません: そのようなファイルやディレクトリはありません

ん???!!!??!?!?

前やった時こんなのでたっけ?状態になりました。

他にも、 find . -name 'Screenshot*' | xargs rmfind . -type f -name '*[Screenshot]*' | xargs rm 等も試してみましたが、ダメ。

結論

xargsコマンドは区切り文字に空白を使っているらしい。

つまり、空白の入ってるファイル名は別々のものと認識され、xargsに渡されてrmが実行されてしまうと。

そのため、区切りを空白文字ではなくnull文字で認識されなければいけないようです。

$ find . -name 'Screenshot*' -print0 | xargs -0 rm

xargsの -0 オプションの形式に合わせて、findコマンドで -print0 を指定してあげる。

これで解決しました。