Categories

Latest comments

WSLのUbuntu 24.04においてGUIアプリの起動が遅い場合はWSLの更新で解決します。

wakairo @wakairo

WSLでUbuntu 24.04の利用を始めてから、 一部のGUIアプリ（meldなど）の起動に異常に時間がかかる問題にずっと悩まされていました。 本日以下のようにコマンドプロンプトでwsl --updateを実行して、この問題がやっと解決しました。

なお、この問題に対する修正は WSL2.5.1で導入されたそうです。

C:\Users\wakai>wsl.exe -v
WSL バージョン: 2.4.11.0
カーネル バージョン: 5.15.167.4-1
WSLg バージョン: 1.0.65
MSRDC バージョン: 1.2.5716
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.26100.1-240331-1435.ge-release
Windows バージョン: 10.0.26200.7462

C:\Users\wakai>wsl --update
更新プログラムを確認しています。
Linux 用 Windows サブシステムをバージョンに更新しています: 2.6.3。

C:\Users\wakai>wsl.exe -v
WSL バージョン: 2.6.3.0
カーネル バージョン: 6.6.87.2-1
WSLg バージョン: 1.0.71
MSRDC バージョン: 1.2.6353
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.26100.1-240331-1435.ge-release
Windows バージョン: 10.0.26200.7462

参考情報

0
Post
Raw
https://www.techtips.page/en/comments/1084

シェルスクリプトで壊さずに全ての引数を別コマンドに引き渡す書き方

wakairo @wakairo
Last edited

基本はダブルクォーテーション付きの"$@"

シェルスクリプトに渡された全ての引数を、そのシェルスクリプト内で別のコマンドに引き渡す場合は"$@"を使います。 例えば、以下のように記述します。

grep -n cat "$@" | sed "s/cat/__CAT__/g" | tee -a ~/foo.log

"$*"や$@（ダブルクォーテーションなし）を使うと、'foo bar'のようなスペースを含む引数がスペースで分割されて壊れてしまいます。

shコマンドに渡すときはsh -c '..."$@"...' -- "$@"

1つの実行コマンドしか受け付けないsudoやssh、docker runなどで、 複数コマンドの実行などの複雑な処理を行いたいときに活躍するのがsh -c '...'です。

シェルスクリプト内でsh -c '...'にすべての引数を渡したいときは、sh -c '..."$@"...' -- "$@"と記述します。 例えば、以下のように記述します。

sudo sh -c 'grep -n cat "$@" | sed "s/cat/__CAT__/g" | tee -a /var/log/foo.log' -- "$@"

先頭のいくつかの引数を取り出して残りを渡す場合（おまけ）

検索ワードのような「固定の引数」と、複数のファイルのような「可変長の引数」が混在しているケースです。 これらをまとめてsudoやssh、docker runなどに投げたい場合は、 -cオプションの文字列内でshiftを使います。

以下は、第一引数が検索文字列、第二引数がその検索文字列を置き換える先の文字列、 第三引数以降はこの検索と置換の対象となるファイル（複数個指定可）となっている例です。

sudo sh -c 'pattern="$1"; replace="$2"; shift 2;
            grep -n "$pattern" "$@" |
            sed "s/$pattern/$replace/g" |
            tee -a /var/log/foo.log' -- "$@"
0
Post
Raw
https://www.techtips.page/en/comments/1083

minitest6にアップデートするとrails testがエラーになる

wakairo @wakairo

現象

2025/12/18にリリースされたminitest 6.0.0のgemにアップデートしたところ、 bin/rails testの実行で以下のエラーが発生して止まりました。ちなみに、テストが1つも無い状態ではこのエラーは発生しませんでした。

Running 1 tests in a single process (parallelization threshold is 50)
Run options: --seed 32547

# Running:

/x/vendor/bundle/ruby/3.4.0/gems/railties-8.0.4/lib/rails/test_unit/line_filtering.rb:7:in 'run': wrong number of arguments (given 3, expected 1..2) (ArgumentError)
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:467:in 'block (2 levels) in Minitest::Runnable.run_suite'
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:463:in 'Array#each'
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:463:in 'block in Minitest::Runnable.run_suite'
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:505:in 'Minitest::Runnable.on_signal'
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:492:in 'Minitest::Runnable.with_info_handler'
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:462:in 'Minitest::Runnable.run_suite'
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:355:in 'block in Minitest.run_all_suites'
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:355:in 'Array#map'
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:355:in 'Minitest.run_all_suites'
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:310:in 'Minitest.run'
        from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:84:in 'block in Minitest.autorun'

とりあえずの回避策

Gemfileのgroup :testのところに以下の記述を追加してminitestのバージョンを6よりも下に設定したところエラーは出なくなりました。

group :test do
  gem "minitest", "< 6"
0
Post
Raw
https://www.techtips.page/en/comments/1082

SprocketsからPropshaftへの移行に関する注意点

wakairo @wakairo

Propshaftへ移行したらSprockets用の設定は削除可能

config/environments/production.rb にある以下の設定はSprocketsの設定なので、 Propshaftへ移行したら、削除可能です。

config.assets.compile = false

参考情報

https://www.techtips.page/ja/comments/658

0
Post
Raw
https://www.techtips.page/en/comments/1081

SprocketsからPropshaftへの移行に関する注意点

wakairo @wakairo

Propshaftは.erbを処理しない

Sprocketsは拡張子が .erb のファイル（例: foo.scss.erb）を処理しますが、Propshaftは処理しません。 そのため、Sprockets で .erb を処理している場合、Propshaftへ移行するには次のいずれかの対応が必要になります。

  • .erb の利用をやめ、プレーンなCSS/SCSSなどに書き換える
  • .erb の処理を、Propshaftに渡す前の前処理として別途組み込む
0
Post
Raw
https://www.techtips.page/en/comments/1080

SprocketsからPropshaftへの移行に関する注意点

wakairo @wakairo

Propshaftへの移行に際して、tailwindcss-railsまたはdartsass-railsを選ぶのもあり

Propshaftの公式移行手順では、CSS関連の処理が必要な場合の選択肢として cssbundling-rails のみ紹介されていますが、 tailwindcss-rails と dartsass-rails という選択肢もあります。cssbundling-railsのREADMEには、選び方のヒントが掲載されています。

0
Post
Raw
https://www.techtips.page/en/comments/1079

SprocketsからPropshaftへの移行に関する注意点

wakairo @wakairo

SprocketsからPropshaftへの移行手順は、 以下のPropshaftの公式手順で基本的には問題ないと思いますが、 この公式手順に記載されていないものを中心に、 移行における注意点をこのTopicで集約できればと思います。

https://github.com/rails/propshaft/blob/main/UPGRADING.md

0
Post
Raw
https://www.techtips.page/en/comments/1078
❤️2
😄1
🔧1

OmniAuthを利用したログインのボタンやリンクではTurboをオフにした方が無難

wakairo @wakairo
Last edited

OmniAuthを利用すると外部サービスの認証情報を用いたログインが可能となりますが、 そのログインのボタンやリンクでは、以下のようにdata: {turbo: false}を付けてTurboをオフにしないと、ログインが機能しない場合があります。

<%= button_to "Login with GitHub", "/auth/github", data: {turbo: false} %>

なお、公式のREADMEにあるRails向けサンプルでもdata: {turbo: false}が用いられています。

また、Rails 7からは、Turboがデフォルト構成に組み込まれ有効になっているため、OmniAuthを利用する際は本件への注意が必要です。

0
Post
Raw
https://www.techtips.page/en/comments/1077

setup-rubyにおける.ruby-versionを用いたバージョン指定

wakairo @wakairo

ruby-version:が無いときのデフォルト動作では、まず.ruby-versionを読みに行くのですね。知りませんでした。

ちなみに少し調べてみたら、2020年のv1.3.0のときから既にそういう仕様のようですね。

それから、railsの新規アプリのGitHub Actionsの設定も現在はruby-version:を省略するようになっていますね。

0
Post
Raw
https://www.techtips.page/en/comments/1076

setup-rubyにおける.ruby-versionを用いたバージョン指定

takuma_tech Takuma @takuma_tech

setup-rubyのREADMEに以下の記述がありますので、 ruby-version:を設定ファイルにあえて書かないことで、.ruby-versionに設定することも可能です。

If the ruby-version input is not specified, .ruby-version is tried first, followed by .tool-versions, followed by mise.toml

設定ファイルをできるだけ簡潔にしたいなら書かない選択もありですし、逆に分かりやすさを重視するなら明示的に書くのも一案です。どちらを取るかは悩ましいところですね。

0
Post
Raw
https://www.techtips.page/en/comments/1075
😄2
🔧1
💯1